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Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Satellite Earth Stations and 
Systems (SES). 

The present document is part 2 of a multi-part deliverable covering Regenerative Satellite Mesh - A (RSM-A) air 
interface MAC/SLC layer specification, as identified below: 

Parti: "General description"; 

Part 2: "MAC layer"; 

Pai-t 3: "SLC layer". 
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Scope 
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Definitions and abbreviations 



3.1 



Definitions 



For the purposes of the present document, the following terms and definitions apply: 

Network Control Centre (NCC): centre that controls the access of the satellite terminal to an IP network and also 
provides element management functions and control of the address resolution and resource management functionality 

satellite payload: part of the satellite that provides air interface functions 

NOTE: The satellite payload operates as a packet switch that provides direct unicast and multicast 
communication between STs at the link layer. 

Satellite Terminal (ST): terminal that is installed in the user premises 

terrestrial host: entity on which application level programs are running 

NOTE: It may be connected directly to the Satellite Terminal or through one or more networks. 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

ACF Access Control Field 

ARM Asynchronous Response Mode 

BCP Bandwidth Control Protocol 

BCS Bandwidth Control Subsystem 

BoD Bandwidth on Demand 

CA Conditional Access 

CoS Class of Service 

CR Constant Rate 

CRC Cyclic Redundancy Check 

CRWB Constant Rate With Burst 

DSA Destination Sub-Address 

EDU Extended Data Unit 

ESN Electronic Serial Number 

HPB High Priority Burst 

HVUL High Volume UpLink 

IP Internet Protocol 

kbps kilo bits per second (thousands of bits per second) 

LLDC Link Layer Data Confidentiality 

LSB Least Significant Bit 

LVLL Low Volume Low Latency 

MAC Medium Access Control 

Mbps Mega bits per second (millions of bits per second) 

MOID Multicast Group ID 

MIP Management Information Packet 

MSB Most Significant Bit 

MTS Management Transport Services 

NCC Network Control Centre 

NIP Network Information Packet 

NPB Normal Priority Burst 

PA Persistent Aloha 

PDS Packet Delivery Service 

PDU Protocol Data Unit 

PEP Performance Enhancing Proxy 

PHY PHYsical 

PTO Packet Transmission Opportunity 

PTP Point-To-Point 
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QoS 


Quality of Service 


RS 


Reed-Solomon 


RSM 


Regenerative Satellite Mesh 


SA 


Slotted Aloha 


SAM 


Security Access Module 


SAP 


Service Access Point 


SAR 


Segmentation And Reassembly 


SDAF 


SatelUte Dependent Adaptation Function 


SDU 


Service Data Unit 


SI-SAP 


SatelUte Independent-SAP 


SLC 


SatelUte Link Control 


SNHA 


Satellite Next Hop Address 


SRF 


SatelUte Routing Field 


ST 


SatelUte Terminal 


TCP 


Transmission Control Protocol 


TDM 


Time Division Multiplexing 


TIP 


Transmission Information Packet 


TOD 


Time Of Day 


UDTS 


User Data Transport Services 


ULPC 


UpLink Power Control 


UTC 


Universal Coordinated Time 



4 SMAC/SLC overview 

4.1 General aspects 

The general aspects of the SMAC/SLC is described in BSM RSM-A, TS 102 189-1 [6]. The present document contains 
the detailed specification of the SMAC/SLC and is organised as follows: 

• Clause 5 describes the SLC procedures including segmentation and reassembly, cyclic redundancy check, 
interfaces, SAPs, service definitions, and service primitives, and diagnostic testing. 

• Clause 6 described the Bandwidth on demand and contention channel access procedures. 

• Clause 7 gives the format and syntax for the SMAC/SLC headers, messages and information elements. 

• Clause 8 lists the air interface parameters called out in the document. 

4.2 Terminal identities and addresses 
4.2.1 ST Site ID 

The ST Site ID is the number by which an instance of ST service is known external to the system. This number is used 
at the system external interfaces, e.g. by an operator at a NOCC user interface or by an ST installer at an installer 
interface. An ST Site ID remains associated with a logical instance of ST service that is defined at the NOCC even if the 
equipment for that ST is replaced and/or the ST is relocated. Hence, an ST Site ID is not fixed to a particular geographic 
location or to a particular unit of equipment. The ST Site ID is unique across all satellite regions, such that no 2 STs will 
have the same ST Site ID, even when they are in different satellite regions. 



4.2.2 Electronic Serial Number (ESN) 



Each unit of ST equipment or SAM is identified by a 48 bit Electronic Serial Number (ESN) which is referred to as an 
ST Equipment ESN or SAM ESN (respectively). The association of an ESN to a unit of ST Equipment or SAM is 
permanent, globally unique, and can be discovered from the hardware by the ST or SAM software. 
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4.2.3 Source ID 



The Source ID is the primary identification of an ST at the network layer. The 24 bit Source ID appears in the RSM-A 
packet header to identify the ST that sent a RSM-A packet. When an ST sends a RSM-A packet to another ST, this 
value is also referred to as the ST Source ID. The Source ID is also used by the payload to identify itself as the source 
when it sends a RSM-A packet to an ST. An ST distinguishes between and keeps track of packets from multiple sources 
via the Source ID. Source IDs are not used for addressing nor switching purposes. 

4.2.4 Bandwidth Control ST ID (BCSTID) 

The 21-bit Bandwidth Control ST ID (BCSTID) is the primary identification of an ST for bandwidth control between 
the ST and the payload. The BCSTID is unique within the scope of the satellite. The BCSTID is not used as the Source 
ID within satellite packet headers. There is no numeric or algorithmic relationship between the BCSTID and the Source 
ID. 

4.2.5 Destination MAC Address 

According to the system model whereby an ST is considered a router, the ST has two types of router interfaces, 
terrestrial interfaces (e.g. Ethernet) and satellite interfaces. Most STs have a single terrestrial interface and a single 
satellite interface, however ST Gateways have multiple of each kind of interface. Corresponding to an Ethernet address 
which is the Medium Access Control (MAC) layer address of an Ethernet terrestrial interface, the Destination MAC 
Address is the MAC layer address of the satellite interface. 

The Destination MAC Address is a 32-bit value that combination of the 1 bit downlink polarization, 10 bit downlink 
microcell ID, and 21-bit Destination Sub-Address sub-fields of the satellite packet header are used for addressing a 
RSM-A packet to an ST virtual port or the management port. Each ST virtual port and management port has a unique 
(within the satellite network) Destination MAC Address. 

4.2.6 Destination Sub-Address (DSA) 

The Destination Sub-Address is the 21 least significant bits of the Destination MAC Address. A Destination 
Sub-Address value is associated with each virtual port and the management port of an ST and is unique within the scope 
of the downlink microcell and polarization. Satellite packets addressed to an ST virtual or management port have the 
corresponding Destination Sub-Address in the "Destination Sub-Address" sub-field of the satellite packet header. 

When the 3 most significant bits of the Destination Sub-Address are all zero, the remaining 18 bits are interpreted as a 
Multicast Group ID (MGID) as described in clause 4.2.7. 

4.2.7 Multicast Group ID (MGID) 

An MGID is used to address a satellite packet to multiple STs. The Multicast Group ID (MGID) is the 18 least 
significant bits of the 21 bit Destination Sub- Address sub-field of a satellite packet header whenever the most 
significant 3 bits of that sub-field are all zero. Hence, MGIDs are a reserved subset of Destination Sub-Address values. 
When an MGID is used, the Satellite Routing Field (SRF) polarization and downlink destination ID sub-fields of the 
satellite packet header may be for a spot beam or shaped beam. In the uplink direction, these SRF sub-fields may 
contain a replication group number that directs the satellite to replicate the packet in the downlink direction. Certain 
MGID values are allocated for special purposes and a range of MGIDs is set aside for management purposes. The 
remaining pool of MGIDs are used for user traffic. This partitioning of MGIDs is defined in clause 7. 

4.2.8 Satellite Next Hop Address (SNHA) 

The Satellite Next Hop Address (SNHA) is an internal satellite network layer address that is assigned to the satellite 
interface of an ST, i.e. to each ST Virtual Port. Each SNHA is a 128-bit IPv6 address value that is unique across the 
entire satellite system, i.e. globally. As such, each ST Virtual Port is uniquely identified by a SNHA; and the set of 
SNHAs for a satellite effectively form a subnet. 

A SNHA is statically configured for each ST Virtual Port at the NOCC and downloaded to the ST. Inter-ST hops for 
routing IP packets across the satellite subnet are expressed in terms of SNHAs. For satellite transmission, each SNHA is 
translated to a Destination MAC Address. 
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The SNHA shall conform to the format of the Aggregatable Global Unicast Address specified in RFC 2373 [9]. The 
lower 32 bits of this format comprise a class E IPv4 address in which the Satellite Network ID is included thereby 
ensuring uniqueness across all satellites of a satellite region. The upper 96 bits of the SNHA have distinct values per 
satellite region thereby ensuring the uniqueness of SNHAs across all satellite regions of the system. 

For typical STs, the Virtual Port to SNHA to Destination MAC address resolution mapping is fixed as there is only one 
Destination MAC address per Virtual Port. 



Satellite Link Control (SLC) sub-layer 



5.1 Overview 

The satellite link control layer is the sub-layer of the Data link layer that is responsible for transmission and reception of 
Service Data Units (SDUs) between peer ST. It supports two modes of delivery, reliable and unreliable. Support of the 
reliable delivery mode is optional. 

The functional responsibilities of the SLC are described below. 

The SLC shall be responsible for maintaining order of transmission of SDUs, such that once SDUs assigned to the same 
class of service, and destined for the same destination region, have been enqueued together in the SLC/MAC layer in 
the appropriate queue for that combination of class of service and destination region, they shall be transmitted in the 
order in which they were enquired. 

The SLC is responsible for building Extended Data Units (EDUs) by compressing and/or encrypting SDUs, and adding 
security headers, frame headers, extension headers and Cyclic Redundancy Checks (CRCs) to SDUs as appropriate. The 
construction of EDUs is described in clause 5.6. Figure 5.1 illustrates the SLC functions necessary to build an EDU 
from an SDU. 
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Extended Data Unit (EDU) 

Figure 5.1 : Construction of an EDU 

Implementation of compression algorithm at the ST is optional. Compression, if supported, can be applied 
independently to individual SDUs. Compression is described in clause 5.2. 

Over-the-air data encryption includes both point-to-point data transfer, called Link Layer Data Confidentiality (LLDC) 
and data multicasting, called Conditional Access (CA). Such encryption is performed per SDU. Security headers are 
also generated by the SLC. Data security is described in clause 5.3. 

The SLC is responsible for the generation of a CRC per SDU. The CRC is described in clause 5.4. The SLC sub-layer 
shall calculate the CRC based only on the encrypted and/or compressed SDU if the SDU is encrypted and/or 
compressed but shall not include the security header, if the SDU is encrypted, in the calculation. The SLC sub-layer 
shall calculate the CRC based only on the SDU if the SDU is not encrypted or compressed. 

The SLC performs peer-to-peer signalling using two methods, namely SLC extension headers, which are effectively 
peer-to-peer SLC messages and the frame header. The SLC extension header is used for capability recognition and 
reconciliation procedures at start of a session. When two STs of different capabilities have to communicate with each 
other, the transmitting ST starts off with a transmission mode set to what it believes the receiver can support and based 
on feedback from the receiver, it may modify the mode to a more compatible and/or optimal mode. This protocol is 
described in clause 5.5. The frame header is used for other types of SLC peer-to-peer signalling such as diagnostic 
testing. 

The SLC is responsible for segmentation and reassembly of EDUs. This function is described in clause 5.6. 

Delivery of data in-sequence to the peer using the reliable/unreliable mode of delivery is affected by the SLC header 
construction as described in clause 5.6 for unreliable mode and in clause 5.7 for reliable mode delivery. 

The SLC is responsible for support of diagnostic test procedures. This is a peer-to-peer protocol described in clause 5.8. 
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Interaction with other ST protocol layers and with other ST management entities are described in clause 5.9. 

The SLC is responsible for delivering 100-byte SLC-PDUs to the MAC sub-layer for transmission on the uplink and is 
responsible for receiving 100-byte SLC-PDUs from the MAC sub-layer, which the MAC has received on the downlink. 

Figure 5.2 shows the terminology used in the SLC/MAC description in clauses 5, 6 and 7. 



SDU 



Input to SLC from IP 
IP packets or equivalent 



SLC headers 



I 



EDU 


.■•••■■' / \ 



















MAC heade 




Input to SAR 
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Uplink MAC Block = 220 bytes 



SLC-PDU SLC-PDU 



SLC-PDU 



Downlink MAC Block = 216 bytes 

RSM-A Packet = 

MAC header -i- SLC-PDU = 108 bytes 



Figure 5.2: Terminology of the SLC/IUIAC 



5.1.1 Modes of operation 



5.1.1.1 



SLC-unack mode 



In SLC-unack mode, data is sent as a sequential data stream without any feedback from the receiver. The function of the 
SLC in this mode is to construct SLC segments from EDU segments before transmission and to recover EDUs from 
received SLC segments on the receiving side. 

An SLC entity operating in unacknowledged mode essentially comprises of two components: 

1) The segmentation component segments an EDU before transmission, including the application of appropriate 
SLC headers. The segmentation procedure is detailed in clause 5.6.2. 

2) The reassembly component reassembles the received segments to recover, if possible, the original EDU. In 
addition, fields of the SLC header are used for missing packet detection at the receiver. The Reassembly 
procedure is described in clause 5.6.3. 
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5.1.1.2 SLC-ack mode 



In SLC-ack mode, reliable delivery of the data is ensured using a modified sliding-window ARQ protocol. The SLC 
sub-layer may support a mode of operation wherein it offers a packet stream service with reliable delivery. This is the 
acknowledged mode of operation (SLC-ack mode). The receiving ST uses SLC acknowledgement packets to give 
feedback to the sender about the SLC segments received. The Sending ST and Receiving ST operate in a point-to-point, 
and unbalanced configuration. The Sending ST is responsible for initiating transmission, and establishing and 
maintaining the link. The Receiving ST can initiate acknowledgement packets with or without explicit permission from 
the Sending ST. Hence, while transferring data, the Sending ST and the Receiving ST communicate in Asynchronous 
Response Mode (ARM). 

A receiving ST which does not support SLC ACK-mode shall drop SLC-PDUs transmitted in ACK-mode. The 
transmitting ST which supports ACK-mode shall be responsible to determine if the peer ST also supports ACK mode. 

5.1.1.3 SLC-transparent mode 

In SLC-transparent mode, SDU are segmented to fit within RSM-A packets but no SLC headers are applied. 

5.1 .2 Procedure description 

5.1 .2.1 Procedures at transmitting side 

The SLC sub-layer conducts the following procedures at the sending side: 

compression (optional); 

data encryption; 

Cyclic Redundancy Check computation; 

SLC peer-to-peer capabilities negotiation (optional for an ST which only supports the ST basic capabilities set 
in annex D); 

SDU Segmentation; 

recovery from SLC segment lost, via retransmission of data (optional); 

diagnostic test procedures. 

5.1 .2.2 Procedures at receiving side 

The SLC sub-layer conducts the following procedures at the receiving side: 

decompression (optional); 

data decryption; 

error detection via CRC; 

SLC peer-to-peer capabilities negotiation (optional for an ST which only supports the ST basic capabilities set 
in annex D); 

SLC Reassembly; 

recovery from SLC segment loss, via acknowledge mode ARQ protocol (optional); 

diagnostic test procedures. 



£75/ 



18 



ETSI TS 102 189-2 VI. 1.1 (2004-03) 



5.1 .3 Backwards compatibility requirements 

An ST shall be able to operate in a mode consistent with the ST basic capability set as defined in annex D. An ST is not 
required to support capabilities beyond those contained in the ST basic capability set. An ST which supports capabilities 
beyond those listed in the ST basic capability set shall be able to determine the capabilities of a peer ST and shall be 
able to, at least, operate with the ST basic capability set with any peer ST. 

5.2 Compression 

Compression is not presently supported. 



5.3 Security procedures 



Security procedures include capacity protection, and user data privacy, i.e. link layer confidentiality and conditional 

access. 

Capacity protection is assured by the SAM, which is required for a ST to operate within a RSM-A system. The RSM-A 
MAC/SLC protocols enable capacity protection negotiation between the satellite and the SAM but are independent of 
the actual capacity protection algorithms. 

User data privacy at the link layer is under the control of the satellite network operator and its customers (wholesalers, 
retailers and end users). The RSM-A protocol design accommodates link layer data security without mandating it or 
limiting the algorithms by specification. The optional security header specified in clause 7, allows receiving terminals to 
recognize encrypted packets and then either drop them or negotiate with the sending terminal. 

The security header allows the service provider to configure closed user groups which can engage in secure data 
exchange using appropriate security algorithms in their terminals to provide encryption at the link layer. In this case, the 
security header allows receivers of such data to choose keys and other relevant decryption input appropriately. STs not 
configured to be members of the closed user group will not have received key material from the service provider and 
would therefore be unable to decrypt the packets should they receive or intercept them. 



5.4 Cyclic Redundancy Check 



An N-bit Cyclic Redundancy Check (CRC-ST-N) (where N is 16, 32, or 64) is applied to the data block for error 
detection at the receiver. The CRC shall be computed on the all the data octets. If the data is encrypted, then the CRC 
shall be computed on the encrypted data and the encrypted padding octets if any. The CRC generator polynomials are 
shown in table 5.1. 

Table 5.1 : CRC generator polynomials 



CRC Type 


CRC-ST-N 


Generator polynomial 





No CRC 


None 


1 


CRG-ST-16 


Gi5(D) = D16+D15+D2^1 


2 


CRC-ST-32 


632(0) = D32 + D26 + D23 + D22 + D^^ + 0^2 + D^^ + 

D10 + d8 + D^ + D5 + d4 + d2 + D +1 


3 


GRG-ST-64 


Ge4(D) = d64 + d4 + d3 + D + 1 



An ST shall apply the correct generator polynomial based on the length of the SDL using the following rules: 

If <= SDL length < THl, use CRC Type = 

If THl <= SDL length < TH2, use CRC Type = 1 

If TH2 <= SDL length < TH3, use CRC Type = 2 

If TH3 <= SDL length, use CRC Type = 3 
THl, TH2 and TH3 are defined in clause 8. 
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CRC Type is described in clause 7.4.3.7. 

The N-bit CRC sequence {c (0), c (1), ...c (N-1)} shall be the ones complement of the sum (modulo 2) of: 

• the remainder of the division (modulo 2) by the CRC generator polynomial, of the product of 
DK by the N-bit CRC initial value; 

• the remainder of the division (modulo 2) by the CRC generator polynomial, of the product of 
DN by the content of the K-bit data block {d (0), d (1), and d (K-1)}. 

where: 

K is the number of bits in the data blocks {d (0), d (1), and d (K-1)}; 

N is the number of bits in the CRC (16, 32 or 64); 

the CRC initial value for each CRC shall be all Is. 

As a typical implementation at the sending side, the initial content of the register of the device computing the remainder 
of the division is preset to all- Is and is then modified by division by the generator polynomial (as described above) on 
the complete data block. 

The resulting N-bit CRC sequence shall be mapped into the CRC field as follows: 

Table 5.2: Ordering of CRC bits for CRC-ST-16 



(MSB) 
Bit? 


Bite 


Bits 


Bit 4 


Bit 3 


Bit 2 


Biti 


(LSB) 
BitO 


Byte 


c(15) 


c(14) 


c(13) 


c(12) 


c(11) 


c(10) 


c(9) 


c(8) 





c(7) 


c(6) 


c(5) 


c(4) 


c(3) 


c(2) 


c(1) 


c(0) 


1 


Table 5.3: Ordering of CRC bits for CRC-ST-32 


(MSB) 
Bit? 


Bite 


Bits 


Bit 4 


Bit 3 


Bit 2 


Biti 


(LSB) 
BitO 


Byte 


c(31) 


c(30) 


c(29) 


c(28) 


c(27) 


c(26) 


c(25) 


c(24) 





c(23) 


c(22) 


c(21) 


c(20) 


c(19) 


c(18) 


c(17) 


c(16) 


1 


c(15) 


c(14) 


c(13) 


c(12) 


c(11) 


c(10) 


c(9) 


c(8) 


2 


c(7) 


c(6) 


c(5) 


c(4) 


c(3) 


c(2) 


c(1) 


c(0) 


3 


Table 5.4: Ordering of CRC bits for CRC-ST-64 


(MSB) 
Bit? 


Bite 


Bits 


Bit 4 


Bit 3 


Bit 2 


Biti 


(LSB) 
BitO 


Byte 


c(63) 


c(62) 


c(61) 


c(60) 


c(59) 


c(58) 


c(57) 


c(56) 





c(55) 


c(54) 


c(53) 


c(52) 


c(51) 


c(50) 


c(49) 


c(48) 


1 


c(47) 


c(46) 


c(45) 


c(44) 


c(43) 


c(42) 


c(41) 


c(40) 


2 


c(39) 


c(38) 


c(37) 


c(36) 


c(35) 


c(34) 


c(33) 


c(32) 


3 


c(31) 


c(30) 


c(29) 


c(28) 


c(27) 


c(26) 


c(25) 


c(24) 


4 


c(23) 


c(22) 


c(21) 


c(20) 


c(19) 


c(18) 


c(17) 


c(16) 


5 


c(15) 


c(14) 


c(13) 


c(12) 


c(11) 


c(10) 


c(9) 


c(8) 


6 


c(7) 


c(6) 


c(5) 


c(4) 


c(3) 


c(2) 


c(1) 


c(0) 


7 



NOTE: The CRC bit is transmitted in "natural" bit order (i.e. same order as the data block). This is the reverse of 
the ITU CRC bit ordering (in the ITU serial interface standards such as LAP.D; LAP.M; the CRC bits are 
sent in reverse order with respect to the order of the bit transmission of the data block). 
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These CRC requirements assume the following pseudo code implementation: 

while (Message is not exhausted) { 

Table_index = (Most significant 4-bit nibble of the CRC register) xor (Most significant 4-bit nibble of 
the message) 

CRC_register = CRC_register left shift by 4 bits 

Message = Message left shift by 4 bits 

CRC_register = CRC_register xor Table_value (Table_index) 

} 
Examples of CRC-ST-16, CRC-ST-32, and CRC-ST-64 calculated for different inputs are given in annex E. 



5.5 Special messaging procedures 



The RSM-A frame header and extension header are provided for future extensions to the air interface. Special handling 
for reception of unrecognised headers is defined in clause 5.6.3. 

5.6 Segmentation and reassembly 

5.6.1 Session creation 

5.6.1 .1 Session creation on the transmit side 

An internal classification function within the ST determines if an SDU is to be sent using SLC unack-mode or SLC 
ack-mode. Only SLC unack mode is described in this clause. For a description of SLC ack-mode, see clause 5.7. 

Before sending a segmented EDU, the ST shall generate a session identifier according to the rules presented below. A 
SAR session is uniquely defined by the combination of characteristics including SLC mode (either unack-mode or 
ack-mode), the Source ID (see clause 4.2.3), the session number (0-63) selected by the source ST, and the Destination 
MAC address (see clause 4.2.5). The session identifier shall be unique for all sessions between the initiating ST and a 
Destination MAC address. When the Destination MAC address is a multicast group, SLC ack-mode shall not be used. 
Within a single SLC session, all segments of an EDU shall be sent before any segment of another EDU may be sent. 

5.6.1 .2 Session creation on the receive side 

SLC Layer Management entity at the Receiving ST creates appropriate per-session data structures, as necessary to 
reassemble an EDU, upon receiving an SLC segment with First bit set and there is no such pre-existing session, 
uniquely defined by a combination of characteristics described in clause 5.6.1.1. The session is established in 
acknowledged or unacknowledged mode based on the value set in the SLC control sub-field in the MAC header. A 
session creation shall be aborted if the first packet indicates a mode or a feature that the receiving ST does not or cannot 
support. 

5.6.2 Segmentation 

The segmentation function segments an Extended Data Unit (EDU), described below, into segments that can be fit into 
empty or partially empty SLC-PDUs. Segmentation of EDUs must be done strictly in the order of presentation to the 
MAC layer for transmission. 

A segmented EDU has one First segment, zero or more Middle segments, and one Last segment. An SLC header 
corresponding to each segment type is prepended to each segment, see clause 7.4.1. The First-type SLC header also 
indicates the possible use of various features and the corresponding presence, within the EDU, of fields necessary for 
such features. 
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An SLC header is also defined for a Whole segment, namely for an EDU that does not require breaking into multiple 
smaller pieces before transmission. Like the First-type SLC header, the Whole-type SLC header also indicates the 
possible use of various features. 

Terms such as "segment", "segmentation", "segmented", etc. shall be interpreted hereafter as also including a case of a 
Whole-type SLC header prepended to an EDU that is not broken into multiple smaller pieces. Such terms shall also be 
interpreted as including the case of an EDU being segmented in a fashion which yields zero EDU bytes in a Last 
segment, i.e. the EDU's Last segment consists entirely of a Last-type SLC header (this case is explained the description 
of the bytes in last segment field in clause 5.6.2.2). 

5.6.2.1 Extended Data Unit (EDU) construction 

In order to specify the segmentation procedure, it is useful to define an Extended Data Unit (EDU) as the construct 
formed from an SDU after applying one or more of the following, which are hereafter collectively designated as EDU 
Features: 

compression; 

encryption, with security header for link-layer data confidentiality; 

a CRC, for data integrity checking; 

a Frame header; 

an SLC Extension header. 

An EDU is defined more rigorously by the output of following procedure applied to an SDU (with no gaps allowed 
after elements prepended to the SDU or before elements appended to the SDU): 

1) If compression is required, compress the SDU. 

2) If encryption is required, encrypt the result of the previous step, and prepend a Security header. 

3) If a CRC is required, calculate it upon the result of the previous step, ignoring the possible presence of the 
Security header. 

4) If a Frame header is required, prepend it to the result of the previous step. 

5) If an SLC extension header is required, prepend it to the result of the previous step. 

NOTE: The output of this procedure is termed an Extended Data Unit even if no EDU Special Features are 
employed, i.e. even if the procedure's output and the corresponding input SDU are identical. 

5.6.2.2 Segmentation rules 

The following rules apply for segmenting an EDU, and for "packing" of multiple segments within a RSM-A packet: 

1) An EDU shall be segmented before transmission. 

2) The SLC mode, either unack-mode or ack-mode, for transmitting an EDU shall not change once any segment 
of the EDU has been transmitted. 

3) An SLC header of type First, Middle, Last, or Whole, as appropriate, and bearing a session number and packet 
sequence number, shall be prepended upon each segment. 

4) Special features of the EDU shall be appropriately indicated in First-type and Whole-type SLC headers. 

5) The session number in an SLC header may be chosen arbitrarily, but must be the same in the SLC headers of 
all segments of a segmented EDU. That is, segments of an EDU may not be sent using multiple SLC sessions. 

6) An ST shall not interleave segments of multiple EDUs within a single SLC session. Interleaving segments of 
multiple EDUs of different SLC sessions is permitted, but the segments of each EDU must be sent in order as 
prescribed below. 

7) The packet sequence number may be chosen arbitrarily for a First-type or Whole-type SLC header. 
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8) The packet sequence numbers in SLC headers of consecutive segments of a segmented EDIT must increase 
consecutively. Packet sequence numbers roll over: if the maximum positive packet sequence number value is 
used in the SLC header for a segment, then the value zero shall be used for the packet sequence number of the 
next segment, if any, of the same EDU. 

9) Consecutive segments of a segmented EDU must be sent consecutively within an SLC session. In SLC 
unack-mode, an EDU shall be discarded if not all of its segments arrive in order. 

10) A First segment must extend to the end of an SLC-PDU. 

11) A Middle segment, with its associated Middle-type SLC header, must occupy an entire SLC-PDU. 

12) A Last segment, with its associated Last-type SLC header, must be positioned within an SLC-PDU and at the 
start of the SLC-PDU. 

13) An SLC segment may bear at most one each of Extension header. Frame header and Security header. If the 
EDU bears an SLC Extension header, a Frame header, and/or a Security header, all bytes of all such headers 
must be carried within a single segment (either a First or Whole segment). 

14) The bytes in last segment field, in a Whole-type or Last-type SLC header, indicates the number of EDU bytes 
in the segment, beginning with the first segment byte following the aforementioned SLC header. This field 
assumes non-negative integer values. The bytes in last segment field assumes a value of zero in the case of an 
EDU being segmented so that the EDU's last byte is the last byte of the payload field of a RSM-A packet, and 
a Last-type SLC header for that EDU follows immediately thereafter in the SLC session. 

15) One segment may be followed immediately by another segment within a single RSM-A packet. However, all 
the segments packed into a single RSM-A packet must be associated with different EDUs, and no gaps are 
permitted between segments. 

16) A SLC-PDU may be packed with SLC unack-mode segments, or with SLC ack-mode segments, but not both. 

17) If SLC segments do not fill up the entire SLC-PDU, the SLC sub-layer shall use padding bytes to ensure that 
the length of the SLC-PDU is 100 bytes. 

18) An ST shall support processing the following examples of multiple segments packed within a single received 
SLC-PDU: 

A Last segment, followed by a First segment. 

A Last segment, followed by a Whole segment, followed by zero or more padding bytes. 

A Last segment, followed by a Whole segment, followed by a First segment. 

A Whole segment, followed by a Whole segment, followed by zero or more padding bytes. 

A Whole segment, followed by a First segment. 

19) A zero length EDU shall not be transmitted. 

20) An EDU may carry zero bytes of SDU if an extension header is present in the EDU. 

21) An extension header's length shall not exceed 40 bytes. 



5.6.3 Reassembly 



The SLC sub-layer receives SLC-PDUs. For each session, the SLC sub-layer maintains a next expected packet 
sequence number in SLC-unack mode or a window of expected sequence number in SLC-ack mode. A segment's packet 
sequence number is contained in that segment's SLC header. The next expected sequence number is initialized, upon 
receiving a First SLC header, to the packet sequence number carried in that header. The next expected packet sequence 
number is incremented with each SLC-PDU received. In SLC-unack mode, if a received segment's sequence number 
does not match the next expected sequence number for that SLC session, indicating a loss or re-ordering of segments, 
all segments of that SLC session are discarded. However, a Whole segment may bear any packet sequence number and 
so would not be discarded. 
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1) The following rules apply for processing a received SLC segment within an SLC-PDU. The SLC sub-layer 
shall deliver packets in order of arrival to the upper layers. If there are missing segments for a certain EDU, the 
other segments belonging to that EDU are discarded. Each EDU shall be processed for reassembly 
independently of other EDUs. 

2) The SLC sub-layer shall start a Reassembly_timer (see clause 8) for an SLC session upon receiving a First 
segment. An SLC session's Reassembly_timer shall be reset each time another in-order Middle segment for 
that SLC session is received and shall be cancelled upon receipt of an in-order Last segment for that SLC 
session. 

3) If the Reassembly_timer for an SLC session expires, all received segments for that session shall be discarded. 

4) When the First segment or Whole segment of an EDU in a single SLC-PDU is received, the SLC sub-layer 
notes the settings of the Cmp, Frame, Sec, CRC and E fields (see clause 7.4.3). These values apply to all other 
segments of the same EDU as applicable. 

5) If the SLC header indicates that it is a Whole or the Last segment of a packet , the receiving ST uses the Bytes 
in Last Segment field to identify the length of that segment. If, within the same SLC-PDU, the byte 
immediately following the end of that segment is non-zero, the SLc sub-layer shall try to interpret the bytes 
following the aforementioned segment as the SLC header for a segment for another EDU. 

6) If the SLC header indicates a CRC, the ST shall compute the CRC for the EDU after reassembling all the 
segments of that EDU. If the CRC does not match, the EDU shall be discarded. 

7) If a security header exists in the EDU, the EDU shall be decrypted after reassembly, on the basis of the 
security header contents. 

8) If the SLC header indicates compression was employed before transmission, the receiving ST shall 
decompress the EDU. 

9) If a frame header is present the SDU shall be delivered to the ST specific entity indicated by the frame header 
contents. 

10) If an extension header is present, the extension header shall be delivered to the ST-specific entity indicated by 
the extension header contents. 

11) If an ST should receive a segment bearing an extension header with a type not supported by the ST, then the 
ST shall ignore the entire extension header, but shall otherwise regard the entire segment bearing the extension 
header. 

12) An ST shall discard a segment upon receipt if any of the following should be true: 

The segment does not comply with the segmentation rules specified in clause 5.6.2.2. 

The segment is a Whole or Last segment, and, based upon the position of the segment with the RSM-A 
packet, the Bytes in Last Segment field indicates more bytes than are available until the end of the 
RSM-A packet. 

The segment bears a frame header value not supported by the ST. 

The segment bears an extension header indicating a length exceeding 40 bytes. 

The segment bears an extension header, and, based upon the position of the segment within the RSM-A 
packet, the extension header length field indicates more bytes than are available until the end of the 
RSM-A packet. 



£75/ 



24 ETSI TS 1 02 1 89-2 V1 .1 .1 (2004-03) 

5.6.4 Session termination 

5.6.4.1 Session termination on the transmit side 

In unacknowledged mode, there are different cases where an active session is terminated, i.e. any data structures 
associated with that SLC session may be freed and the SLC session number may be re-used. These cases are defined 
below: 

• For unacknowledged-mode, the SLC sub-layer may close a session immediately upon transmitting the Last 
segment of an EDU. 

• SLC entity may also close a session due to an unrecoverable error. Any packets pending internally for that 
SLC session are flushed. Assigned slots that have not been used are also lost. 

The upper layers may request an abrupt termination of an existing session. In this case, the SLC sub-layer may abort 
that session and drop all untransmitted segments. 

5.6.4.2 Session termination on the receive side 

In unacknowledged mode, there are different cases where an active session is terminated. The closing of session is an 
explicit decision of the implementation. The cases are defined below: 

• The SLC sub-layer may close a session normally after receiving all the segments of an EDU. 

• The SLC sub-layer may close the session when any missing packet(s) is detected. In this case session is closed 
abnormally. 

• The SLC sub-layer may close the session when the Reassembly_timer expires. 

• In normal or abnormal termination all the resources allocated to the session are released. When session is 
terminated abnormally partially received EDUs are dropped. 

5.7 Ack-mode 

SLC Ack-mode is not currently supported. 

5.8 Diagnostic test procedure 

5.8.1 Overview 

The diagnostics module injects diagnostic SLC test messages into the system and further, receives the diagnostic SLC 
test messages from the link layer for analysis. It interacts only with the SLC sub-layer. Two distinct types of tests are 
possible. One test is used to measure peer-to-peer SLC delay and the other is used to measure satellite delay. These are 
distinguished by a message type field within the message format (see clause 7.5.9). A receiving ST shall drop any SLC 
test message type it receives which it does not support. Both test message types require a frame header (see 
clause 7.4.5). 

5.8.2 Interfaces, SAPs, service definitions and service primitives 

The diagnostic module does not provide any service directly to any other layer. It uses the SLC-SAP to deliver SLC 
test-messages to the SLC layer and receive SLC test-messages from that layer. 

5.8.3 SLC peer-to-peer delay tests 

An ST shall support SLC peer-to-peer delay tests. 
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5.8.3.1 Initiating ST procedure description 

The ST which initiates the test procedure does so by creating a new test with a unique test id. If sequencing is required 
and if the ST supports sequencing the starting sequence number shall be 0. The ST shall create the appropriate SLC test 
messages using the format specified in clause 7.5.9. The initiating ST shall encode the time received field as all zeros. 
The destinations, periods and rate at which these messages are created are configured within the diagnostics module. 

If the initiating ST is to collect the statistics, it shall set the R/C bit to "1". If the receiving ST is to collect the statistics, 
the initiating ST shall set the R/C bit to "0". 

Once the SLC test message is created, the diagnostics module uses the SLC_TESTDATA.req primitive to transfer these 
messages to the SLC layer. The initiating ST shall time stamp the SLC test message using the time sent field prior to 
calculation of the CRC. The SLC shall calculate a CRC, create a frame header and perform segmentation and may 
support encryption of SLC test messages as required. The SLC shall not perform compression or other SLC services on 
the SLC test messages. The test module may use any combination of delivery mode or UDTS, as per the testing 
requirements. 

If the destination address is a point-to-point address, the initiating ST does not need to explicitly mark the list of 
addresses field with the ST Site ID (see clause 4.2.1) of the recipient. If the address is a multicast destination and the 
test requires a response from a particular receiving ST, the initiating ST shall explicitly add the receiving ST's ST Site 
ID to the list of recipients in the transmitted message. On receiving the response from the receiving side, the receiving 
ST's SLC sub-layer reassembles the returned SLC test message and after checking the CRC shall time stamp the 
message if required and transfers it to the local diagnostics module for further processing. 

5.8.3.2 Receiving ST procedures 

If the R/C bit is set to "1"; and 

• The packet has been sent point-to-point to the receiving ST or; 



• 



The packet has been being sent to a multicast address, and the receiving ST's ST Site ID is present in the list of 
recipients field; 



the receiving ST shall to respond to the initiating ST. 

To respond to the initiating ST, the receiving ST shall time stamp the received time field immediately after checking the 
CRC of the received SLC test message. If there was more than one receiving ST's ST Site ID in the list of recipients, the 
receiving ST shall recode the list of recipients field with only its own ST Site ID and code the remainder of the list of 
recipients field with all zeros. 

The receiving ST responding to a multicast SLC test message shall delete all the padding bytes prior to computing the 
CRC and transmitting the reformatted message back to the initiating ST. The receiving STs, responding to a 
point-to-point SLC test message with packet type satellite connectivity QoS packet, specified channel test packet or 
background QoS packet, shall delete all the padding bytes prior to computing the CRC and transmitting the reformatted 
message back to the initiating ST. The SLC test message is transmitted back to the initiating ST using the Destination 
MAC address contained in the Return MAC Address field. A drop class of or 1 may be used for the response. 

If the R/C bit is set to "0", the receiving ST should collect the message statistics instead of responding, keeping 
distinction of test IDs and sequence numbers. If a test ID/sequence number combination is received for which there is 
already a record, the newest information shall replace the older record. A receiving ST is not required to support the 
collection of statistics when receiving SLC test messages from another ST. Such an ST shall drop the received SLC test 
messages with R/C bit set to "0". 

If the receiving ST receives a SLC test message with packet type indicating Satellite Loopback packet and the receiving 
ST was not the initiator, the receiving ST shall drop the message. 

5.8.4 Satellite delay tests 

An ST should support satellite delay tests. This test is not in the ST basic capability set. See annex D. 
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5.8.4.1 Initiating ST procedure description 

The ST which initiates the test procedure does so by creating a new test with a unique test id. If sequencing is required 
and if the ST supports sequencing the starting sequence number shall be 0. The ST shall create the appropriate SLC test 
messages using the format specified in clause 7.5.9. The initiating ST shall encode the time received field as all zeros. 
The destinations, periods and rate at which these messages are created are configured within the diagnostics module. 

If the initiating ST is to collect the statistics, it shall set the R/C bit to "1". If the receiving ST is to collect the statistics, 
the initiating ST shall set the R/C bit to "0". 

Once the SLC test message is created, the diagnostics module uses the SLC_TESTDATA.req primitive to transfer these 
messages to the SLC layer. The initiating ST shall time stamp the SLC test message using the time sent field prior to 
transmission with the uplink time slot and frame number. The SLC shall create a frame header. The SLC shall not 
encrypt, perform compression, or compute a CRC or other SLC services on the SLC test messages. The test module 
may use any combination of delivery mode or UDTS, as per the testing requirements. The SLC test message shall fit 
within one SLC-PDU. 

If the destination address is a point-to-point address, the initiating ST does not need to explicitly mark the list of 
addresses field with the ST Site ID of the recipient. If the address is a multicast destination and the test requires a 
response from a particular receiving ST, the initiating ST shall explicitly add the receiving ST's ST Site ID to the list of 
recipients in the transmitted message. On receiving the response from the receiving side, the initiating ST's SLC 
sub-layer shall transfer it to the local diagnostics module for further processing. 

5.8.4.2 Receiving ST procedures 

If the R/C bit is set to "1"; and 

• The packet has been sent point-to-point to the receiving ST; or 



• 



The packet has been being sent to a multicast address, and the receiving ST's ST Site ID is present in the list of 
recipients field; 



the receiving ST shall respond to the initiating ST. 

To respond to the initiating ST, the receiving ST shall time stamp the received time field with the downlink frame 
number in which the message was received. If there was more than one receiving ST's ST Site ID in the list of 
recipients, the receiving ST shall recode the list of recipients field with only its own ST Site ID and code the remainder 
of the list of recipients field with all zeros. 

The SLC test message is transmitted back to the initiating ST using the Destination MAC address contained in the 
Return MAC Address field. A drop class of or 1 may be used for the response. 

If the R/C bit is set to "0", the receiving ST should collect the message statistics instead of responding, keeping 
distinction of test IDs and sequence numbers. If a test ID/sequence number combination is received for which there is 
already a record, the newest information shall replace the older record. A receiving ST is not required to support the 
collection of statistics when receiving SLC test messages from another ST. Such an ST shall drop the received SLC test 
messages with R/C bit set to "0". 

If the receiving ST receives a SLC test message with packet type indicating Satellite Loopback packet and the receiving 
ST was not the initiator, the receiving ST shall drop the message. A receiving ST is not required to support the 
collection of statistics when receiving SLC test messages from another ST. Such an ST shall drop the received SLC test 
messages. 
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5.9 

5.9.1 

5.9.1.1 



Interfaces, SAPs, service definitions, and service-primitives 
Interfaces with higher layers: IP-SLC 



Service Access Point-SLC-SAP 



The SLC-SAP is used by the upper layers to deUver and receive packets to and from SLC respectively. Packets from the 
IP layer are delivered to the SLC-SAP, and received from the SLC-SAP via the Satellite Dependent Adaptation 
Function (SDAF) as illustrated in figure 5.4. The SDAF adapts between the SI-SAP primitives and the SLC-SAP 
primitives. 

5.9.1 .2 Service definitions 

The services provided by the SLC are as follows: 

• Resource reservation for specific Classes of Service (CoS). 

• Option for acknowledged mode of SDU delivery (not currently supported). 

• Unacknowledged mode of SDU delivery. 

• Segmentation And Reassembly (S AR) of the SDU. 

• Optional compression of SDUs. 

• Option to encrypt/cipher information on flow basis. 

5.9.1.3 Service primitives 

The primitives provided by the SLC sub-layer are listed in table 5.5. 

Table 5.5: SLC sub-layer service primitives 



primitive name 


Type 


Parameters 




Request 


Indication 


Response 


Confirm 




SLC_UNITDATA 


X 








SDU 

Destination IVIAC_Address 

of the source 

Destination IVIAC_Address 

of the destination 

CoS_Profile 


SLC_UNITDATA 




X 






SDU 

Destination IVIAC address 



5.9.1.3.1 



SLC UNITDATA 



The upper layer uses SLC_UNITDATA-request to send the SDU. At the far end, the SDU is delivered to the upper 
layer using the SLC_UNITDATA-indication. 



5.9.1.3.2 



5.9.1.3.2.1 



Primitive parameters 



SDU 



The Service Data Unit (SDU) corresponds to the "payload" of the primitive. The SDU contains the IP packet to be 
transported over the RSM-A network. 
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5.9.1.3.2.2 Destination MAC_Address 
The Destination MAC_Address is defined in clause 4.2.5. 

5.9.1.3.2.3 CoS_Profile 

Tlie CoS_Profile is defined using a set of CoS Tags. These CoS Tags can take the following values. 

Table 5.6 



CoS Tag 


Possible Tag Values 


Class of Service Flow ID 


UDTS (CR, CRWB, NPB, HPB, LVLL, AckReturn) (note 1) 


Encryption 


Yes/No (note 2) 


Compression 


Yes/No (note 3) 


SLC Mode 


SLC Unack/SLC Ack (note 4) 


Destination Type 


MAC replication true, MAC replication false 


NOTE 1 : The Flow_ID defines the Class of Service and also identifies specific flows within certain Classes 
of Service. For CR and CRWB services the Flow_ID is used to indicate specific resource 
reservations using a unique identification number; for NPB and HPB services the FlowJD is used 
to indicate one of four different priority levels. 

NOTE 2: Encryption is defined in clause 5.3. 

NOTE 3: Compression is defined in clause 5.2. 

NOTE 4: SLC Unack mode is defined in clause 5.6. SLC Ack mode is defined in clause 5.7. 



5.9.2 Interface with specific ST entities 



The ST specific entities (e.g. diagnostic test controller, management) can be conceptually considered to use separate 
SAPIs for accessing the services offered by the SLC sub-layer. 

For diagnostic test messages, The SLC shall combine the ST specific frame header with the diagnostic message and 
extract it on the receiving side as described in clause 5.8. 

For management messages, the SLC sub-layer provides a set of Management Transport Services (MTS) as described in 
clause 6.3.4.4. 



5.9.3 Logical interface with peer layer 



The SLC sub-layer has a logical interface (P interface) with peer SLC sub-layer. The P interface can be conceptually 
said to connect two individual SLC entities. The P interface supports multiple sessions between SLC entities, where 
each session corresponds to a specific instance of SLC-SAP service. If there are multiple SLC sessions between two 
STs, it is conceptually equivalent to having multiple connections over the U interface. 

NOTE: All SLC sessions are unidirectional in nature. 

Figure 5.3 also shows the logical SLC-SAP interface between the SLC sub-layer and the upper layers. Note that the 
figure does not show all the layers of protocol stack architecture. 
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IP Layer 



SatelliteDependent Adaptation Function 



IP Layer 



SI-SAP 



I 



SatelliteDependent Adaptation Function 



SI-SAP 



SLC-SAP MAC Addresses 



Satellite Link Control 



Sublayer <;;;^ 



Media Access Control Sublayer 



I 



P-interface 



^~~~]> Satellite Link Control Sublayer 



I 



SLC-SAP MAC Addresses 



Media Access Control Sublayer 



PHY-SAP 



Physical Layer 



I 



PHY-SAP 



Physical Layer 



Figure 5.3: Logical Interface between peer SLC sub-layer 

5.9.4 Satellite Dependent Adaptation Function 

The Satellite Dependent Adaptation Function (SDAF) contains the functions that map between the SLC-SAP services 
and the SI-SAP services. 

The service mapping between the BSM traffic classes TS 102 295 [10] and the RSM-A User Data Transport Services 
(UDTS) is shown in table 5.7. 

Table 5.7: Mapping between BSM traffic classes and RSM-A UDTS 



BSM Traffic Classes [10] 


RSM-A 


TrafficC 
lass 


Service Categories 


UDTS 

(notel) 





Pre-emption, emergency services, essential network 
services 


Any 


1 


Real-Time, Jitter sensitive, high interaction - Fixed 
size cells (VoIP) 


CR 


2 


Real-Time, Jitter sensitive, interactive - Variable size 
packets (Real Time Video) 


CRWB 


3 


Transaction Data, Highly Interactive, (Signalling, 
traffic engineering, PEPs) 


LVLL 
(note 2) 


4 


Transaction Data, PEP, Interactive 


HPB 
(note 2) 


5 


Low Loss Only (Short Transactions, Bulk Data, Video 
Streaming) 


NPB 


6 


Medium loss, higher delay (Traditional Applications of 
IP Networks) 


NPB 


7 


Not specified. Could be used for low priority 
broadcast/multicast traffic or storage networks (with 
reliable higher layer). 


NPB 


NOTE 1 : The RSM-A UDTS are defined in clause 6.3.4.1 . 
NOTE 2: PEP acl<nowledgements are treated as a special case and mapped to 
the UDTS Acl<-Return service. 
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Medium Access Control sub-layer 



6.1 Overview 

Medium Access Control (MAC) is a sub-layer of the Data link layer. This layer shall control the way ST uses its uplink 
resources, i.e. contention channel and the dedicated channel resources. This layer handles the following functions: 

bandwidth negotiations; 

multiplexing of SLC sessions to uplink data channels; 

interaction with security access module; 

layer QoS requirements management; 

discriminate and filter traffic received by the ST; 

MAC block construction; 

scheduling of the outbound traffic; 

receipt of MAC messages; 

contention channel access protocol; 

congestion detection and reporting. 



6.1.1 Modes of operation 



The Medium Access Control sub-layer has two modes of operation. These are the Bandwidth on Demand (BoD) mode 
and the High Volume UpLink (HVUL) mode. If an ST is capable of both HVUL mode and BoD mode, it shall switch 
between the two modes at the command of the NCC within 768 msec. User data service may be interrupted during this 
transition. In the rest of this specification, unless otherwise mentioned, it should be assumed that we are referring to the 
BoD mode of operation. 

6.1.1.1 BoD mode 

In the BoD mode of operation, the ST shares all uplink resources with other STs in the same geographical area based on 
configuration. The contention channels are used by STs for initial access to the system. The bandwidth control protocol 
has to be continuously executed to get resources allocated by the Bandwidth Control Subsystem (BCS) in the network 
for usage on the uplink dedicated channels. The slotted Aloha and persistent Aloha protocols are used for getting 
resources on the uplink contention channels. All STs are continuously required to control the amount of resources they 
use by the use of a token bucket mechanism. 

6.1.1.2 HVUL mode 

In the HVUL mode of operation there are a set of uplink resources reserved for the exclusive usage of the ST, without 
the ST having to execute any protocol or make any explicit request to the network. Consequently, the ST does not have 
to use the contention channels, nor implement the bandwidth control protocol. There is no token-bucket based 
flow-control, because the resources are not shared. However, the ST is required to ensure that the usage of uplink 
resources is distributed between the downlink regions based on configuration from the NCC. This ensures equitable 
handling of data streams to all destinations within the ST. 

6.2 Interfaces, SAPs, service definitions, and service primitives 

This clause gives details on different interfaces that the MAC sub-layer has with other layers and entities. 
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6.2.1 Interface with physical layer : MAC-PHY 

6.2.1 .1 Service Access Point 

This SAP shall provide the means for transfer of RSM-A packet to the physical layer for transmission over the air link. 

6.2.1.2 Service used 

Medium Access Control sub-layer expects the following service from the physical layer: 

• Transmission of RSM-A packet on the assigned channel (contention or dedicated) and timeslot. 

• Current status of radio link. 

6.2.2 Interfaces with layer management entities 

6.2.3 Logical interfaces with peer layer 

The peer to the ST's MAC sub-layer resides in the network. The ST interacts with the Bandwidth Control component on 
the satellite over the "U" interface for negotiating the required channel and bandwidth for both the rate and volume 
traffic. 

This logical interface shall be supported with the set of messages listed in clause 7.5. 

6.3 MAC procedures 

6.3.1 General procedures 
6.3.1.1 Network 

The following MAC procedures are implemented by the network. 

6.3.1.1.1 System information broadcasting 

The network transmits system information in broadcast mode. The system information is classified into the following 
types: 

1) Transmission Information Packet (TIP). This message contains basic information required by the terminal to 
initiate access to the RSM-A system. This message is described in clause 7.5.2. The messages are transmitted 
once per superframe from the network. The ST shall read a complete TIP within the last 5 superframes prior to 
initiating any network access. Further the ST shall declare "downlink failure" if it fails to read a complete TIP 
within the last 5 superframes. 

2) Network Information Packet (NIP) messages. NIP messages include bandwidth assignment, negative 
acknowledgement, and dynamic contention channel assignment messages. These messages are described in 
clause 7.5. 

3) Uplink Power Control Status message. This message is transmitted on a per-uplink frame basis by the system, 
individually for each physical channel. This message contains power and timing adjustment information 
required by the ST to adjust its transmission as well as contention information for contention channels. For 
contention channels, the ST shall read this information in each frame if it needs to access the system. This 
message is described in clause 7.5.3. 

4) Management Information Packet (MIP) messages. Management Information Packets are of two types direct 
and indirect. An ST should be able to operate indefinitely without direct MIP. Both types are generated by the 
network and broadcast to all STs. They contain information required by the ST to register itself with the 
network and negotiate for services. 
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6.3.2 Medium access procedures 
6.3.2.1 Initial access procedure 

A ST that does not have any radio resources currently allocated to it shall make the initial access on a contention 
channel, i.e. a Slotted Aloha (S A) or Persistent Aloha (PA) channel. The use of S A or PA channel is dependent on the 
classification of the traffic by classifier. 

• If the traffic is classified as "constant rate", the ST shall issue a BoD request using the available SA channels 
to get a dedicated rate allocation (refer to clause 6.3.3). 

• If the traffic is classified as "constant rate with burst", the ST shall issue a BoD request using the available S A 
channel to get a dedicated rate allocation and a volume allocation for the excess burst traffic (refer to 

clause 6.3.3). 

• If the traffic is classified as "normal priority burst or high priority burst", it shall issue a BoD request to BCP 
using the SA channel to get a dedicated volume allocation (refer to clause 6.3.3). 

• If the traffic is classified as LVLL, then the ST may use the one of the S A channels to transport them as 
specified in clause 6.3.5.2 or shall issue a BoD request to BCP using the SA channel to get a dedicated volume 
allocation. 



• 



If the traffic is classified as AckReturn, it may set up a PA channel as described in clause 6.3.5.3.2 if PA is 
available. If PA is not available then AckReturn traffic is treated as LVLL traffic (Transmitted on one of S A 
contention channel). 



6.3.3 Bandwidth control procedures 



The bandwidth control protocol for rate requests, volume requests, rate modification and rate de-allocation is essentially 
the same. The ST shall not use bandwidth control procedures for HVUL traffic or for any traffic class which uses 
contention channel for data transfer (see clause 6.3.4). 

An ST is required to request bandwidth assignments from the network in order to transfer rate or volume traffic. An ST 
shall evaluate its bandwidth requirements at least once per uplink frame. 

The ST shall aggregate, or queue, volume traffic requirements according to downlink destination region ID and priority. 
The volume request protocol is described in clause 6.3.3.1. The number of slots requested should reflect the total 
number of packets per queue corresponding to each downlink destination region and priority. For volume requests, the 
ST shall not make a request for more volume than the data it already has queued corresponding to each downlink 
destination region ID / priority pair. 

The ST shall aggregate all rate requirements into two rate requests based on priority (high or low) but independent of 
destination. Each of these requirements is the number of slots per uplink frame required to service all rate requests. The 
protocol for rate requests is described in clause 6.3.3.2. If one of these aggregated rate requirements changes from one 
frame to the next, the ST shall apply the protocol described in clause 6.3.3.3. If one of these requirements changes from 
one frame to the next to a zero value, the ST shall apply the protocol described in clause 6.3.3.4. 

During any frame, the ST may make at most two rate requests (for each priority, i.e. low and high priority traffic). 

The ST shall combine all of its rate and volume bandwidth requirements into one or more bandwidth request messages. 
The bandwidth request message format is described in clause 7.5.4. The ST shall send each bandwidth request message 
to the SAM via the SAM/ST interface(see BSM RSM-A, TS 102 189-3 [7]). The SAM will return each message with a 
4-byte integrity check. The network shall discard all bandwidth request messages which do not contain a valid integrity 
check. 

The ST shall utilise either a slotted aloha contention channel or a previously assigned (dedicated) rate or volume time 
slot to make the request to the satellite. The rule for using previously assigned bandwidth for bandwidth requests is 
defined in clause 6.3.3.1. 

The network shall respond to each bandwidth request message with bandwidth assignment messages and/or negative 
acknowledgement messages rejecting the request. 
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Each bandwidth assignment contains the assigned dedicated resources to be used by the ST. Each assignment contains 
an assignment integrity check. The ST shall pass each assignment to the SAM for permission to use the assigned 
resource. 

An ST shall be able to use all assignments which are received 24 msec prior to the start of the uplink frame for which 
the assignment is made. An ST shall transmit NULL packets in any such assignment, which it does not use for traffic or 
signalling. An ST may use any assignments received between 24 msec prior to the start of frame and just prior to the 
actual assigned time slot. However, an ST shall generate an alarm to the network for all assignment messages which are 
received subsequent to 24 msec prior to the start of the frame for which the assignment is made. 

6.3.3.1 Volume request protocol 

A pair of volume requests is associated with every combination of destination region ID and priority. An allocation 
timer instance is associated with each such volume request pair. For each such pair of requests, the allocation timer's 
timeout value is initialized to BODAllocationMinTimer (see clause 8). The allocation timer's timeout value for each 
request pair is adjusted between this value and BODAllocationMaxTimer (see clause 8) according to the following 
protocol: 

1) When a new queue is created and it is the first queue created for a destination region/priority pair, the 
allocation timer for the destination region/priority pair is initialized to BODAllocationMinTimer (see 
clause 8). When a new queue is created and other queues already exist for this destination region/priority pair, 
the new queue is subject to the current value of allocation timer. 

2) When a new volume request is transmitted from the request pair for a specific combination of destination 
region ID and priority, the allocation timer is started as long as it is not already running. If the timer is already 
running when the request is transmitted, it indicates that there is already a pending request from this pair, and 
so this newly transmitted request must be a follow-up request to that pending request. In such a case, the timer 
continues to run for the pending request. When the last allocation is received for that request, the timer is 
reinitialized to the current timeout value and restarted, for it is now time for the follow-up request to receive 
allocations. It is important to note that the allocation timer's timeout value does not depend on whether or not 
the current request is a follow-up request. The timeout value of the allocation timer for each request pair is 
adjusted by an independent method that is described in the following points. 

3) If the ST receives a bandwidth assignment message containing an assignment corresponding to a volume 
request, it shall stop the allocation timer for that volume request. The allocation timer's timeout value shall be 
reduced by BODAllocationStepTimer (see clause 8), unless it is already at the value BODAllocationMinTimer 
(see clause 8). 

4) If the allocation timer expires and the ST has not received either an assignment or a negative 
acknowledgement, the ST shall increase the value of the allocation timer by BODAllocationStepTimer, unless 
it has already reached the value BODAllocationMaxTimer (see clause 8). The ST shall then 

re-evaluate the bandwidth requirement for that destination region ID/priority pair and transmit a bandwidth 
request message with the new requirement. 

5) If the ST receives a negative acknowledgement, the ST shall behave as per the cause code, see clause 7.5.6. 

6) If the ST receives a ULPC status message indicating a R/S failure (see clause 7.5.3. L5) for the transmitted 
packet containing the bandwidth request message, the ST may then re-evaluate the bandwidth requirement for 
that destination region ID and transmit a bandwidth request message with the new requirement immediately. 
The allocation timer shall be stopped and restarted using the most recently used value for that destination 
region ID. 

7) As more data arrives in a destination region/priority queue, the ST shall request follow-up bandwidth to 
service the new data in that queue. The ST shall set the follow-up bit in the bandwidth request data field and 
may use one of the assigned slots to send a bandwidth request message for additional slots and shall start its 
allocation timer. Other rate and volume bandwidth requests may be aggregated on the same bandwidth request 
message using different bandwidth request data fields. 

8) An ST may have at most two outstanding requests per destination region ID/priority pair outstanding at any 
time. 

9) The ST may request up to BODMaximumBODRequestSize (see clause 8) slots in a single volume request 
message per destination region ID/ priority pair. 
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10) An ST may receive explicit negative acknowledgements for volume request. The ST shall react based on the 
cause code as specified in clause 7.5.6. 

6.3.3.1 .1 Mapping of downlink destination ID into destination region IDs 

The downlink destination ID field is an information element in every MAC header as described in clause 7.3.1.4. Each 
downlink cell has a downlink destination ID. The downlink destination ID field is defined in BSM RSM-A 
TS 102 188-6 [4]. The network maps downlink destination IDs to destination region IDs based on network congestion. 
Thus several destination IDs may be mapped to a single destination region ID if traffic in these downlink cells cause 
mutual congestion. Most downlink cells are not congested and do not cause mutual congestion to each other. These 
downlink destination IDs are all mapped to a default destination region ID value called the wildcard destination region 
ID. The ST shall aggregate volume traffic by destination region ID and priority rather than on downlink destination ID. 
This mapping is transmitted by the network. 

The mapping of downlink destination IDs into destination region IDs may change at any time. This is expected to be an 
infrequent event and the following rules are designed to allow an ST to implement an efficient remapping procedure. 

Following any change to the mapping, the ST shall map all subsequent packet arrivals using the new mapping. The ST 
shall map any packets that were queued up prior to the receipt of the remapping using either the new mapping or the 
previous (old) mapping provided that all such packets are preserved and are transmitted (or retransmitted) using one of 
these two mappings. 

6.3.3.2 Rate request protocol 

Rate requests shall be used for connection oriented traffic, (i.e. all CR traffic as well as the constant rate portion of 
CRWB traffic). The rate requests specifies the number of slots in each uplink frame that a ST requires to meet the 
aggregate rate for all connection-oriented traffic with the same priority. 

1) The ST shall start a response timer with a value BODResponseTimer (see clause 8) when it transmits a 
bandwidth request message containing a rate request for each rate request. It shall set the RETRY counter to 
BODRateRequestRetries (see clause 8). 

2) If the ST Response timer expires, the ST shall do the following. If the RETRY counter is non-zero, the ST 
shall transmit another bandwidth request message with the rate request, restart the response timer and 
decrement the RETRY counter. If the RETRY counter is zero, the ST shall declare failure to the connection 
management entity and abandon the attempt to obtain a rate assignment. If the ST has entered CC transition 
mode (refer to clause 7.5.2.2.10), the ST shall suspend transmitting bandwidth request messages as per the 
protocol, and shall not declare failure to the connection management module. 

3) If the network does not have available bandwidth, it shall transmit a negative acknowledgement message with 
the appropriate cause code. The ST shall react based on the cause code as specified in clause 7.5.6. 

4) If the ST receives bandwidth assignments for the rate requests, the ST shall reset the RETRY counter to 
BODRateRequestRetries. The ST shall restart the response timer for each assignment it receives. If the 
response timer expires while the connection is active, the ST shall handle it as specified in 2) above. 

The network may assign bandwidth for the rate requests every frame or may make an assignment which is valid for 
multiple frames (see clause 7.5.5.1.5). 

If the requesting ST receives an assignment valid for multiple frames, the ST shall use the multiple frame assignment 
until one of the following occurs: 

• The multiple frame assignment expires in which case the ST must stop using the assignment. 



• 



The ST receives an assignment that replaces the multiple frame assignment in which case the ST abandons the 
multiple frame assignment and uses the replacement. 



If the ST misses an assignment for a frame (e.g. due to rain fade), then it shall not transmit for that frame. The ST shall 
wait until it receives a bandwidth assignment message that specifies it is a rate assignment to resume transmission. If 
the ST receives the assignment valid for multiple frames then it shall stop the response timer and restart the response 
timer after finishing the multiple frame allocation. 
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6.3.3.3 Rate modification procedure 



The ST shall re-evaluate the aggregate rate requirement for both low and high priority rates every uplink frame. If the 
aggregate rate is changed, either due to a new connection becoming active or due to termination of an existing 
connection, the ST shall transmit a new bandwidth request message, requesting the rate modification to the new 
aggregate rate. The ST shell set the request action information element of the bandwidth request message as described 
in clause 7.5.4.4.4. 

The network shall respond with a bandwidth assignment message or a negative acknowledgement message. The ST 
shall assume the rate modification was successful only when it receives the first bandwidth assignment message with 
the new rate. 

1) The ST shall start a response timer with a value BODResponseTimer when it transmits a bandwidth request 
message containing a rate modification for each rate request. It shall set the RETRY counter to 
BODRateRequestRetries. 

2) If the ST Response timer expires, the ST shall do the following. If the RETRY counter is non-zero, the ST 
shall transmit another bandwidth request message with the rate modification, restart the response timer and 
decrement the RETRY counter. If the RETRY counter is zero, the ST shall declare failure to the connection 
management entity and abandon the attempt to modify the rate. If the ST has entered CC transition mode (refer 
to clause 7.5.2.2.10), the ST shall suspend transmitting bandwidth request messages as per the protocol, and 
shall not declare failure to the connection management module. 

3) If the ST is requesting more rate bandwidth and network does not have available bandwidth, it shall transmit a 
negative acknowledgement message with the appropriate cause code. The ST shall react based on the cause 
code as specified in clause 7.5.6. 

4) If the ST receives bandwidth assignments for the modified rate, the ST shall reset the RETRY counter to 
BoDRateRequestRetries. The ST shall assume that the rate modification procedure has been successful. 

6.3.3.4 Rate de-allocation procedure 

The network shall continue to assign bandwidth to the ST for the aggregate rate until the ST transmits a bandwidth 
request message with the request action information element (see clause 7.5.4.4.4) set to cancel or de-allocate the 
existing rate. There is no explicit response from the network for the de-allocation request. The ST should monitor the 
bandwidth assignment messages and check whether the assignment has been stopped. The assigned rates for each 
priority are independent. 

The following is the protocol for rate de-allocation: 

1) The ST shall transmit a bandwidth request message requesting rate de-allocation and start the response timer. 

2) If the network receives the rate de-allocation message, it shall delete the request from its internal queue and 
stop making the rate assignments for the ST. 

3) The ST shall continue to monitor all bandwidth assignment messages for the rate assignment. While the 
deallocation request is pending, failure to receive a bandwidth assignment message with the previously 
requested rate for two consecutive frames shall be interpreted by the ST to indicate a successful deallocation. 
The ST shall not restart response timer on receipt of a bandwidth assignment message which continues to 
assign the rate. 

4) If the response timer expires and deallocation is still not successful, i.e. the ST is still receiving rate 
assignments, it shall send another bandwidth request message for the rate deallocation and restart the response 
timer. This shall continue indefinitely until the condition described in the step 3 has been achieved. 
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6.3.4 Bandwidth management procedures 

The ST classifies the data transiting over the air-interface into different flows, each being associated with certain User 
Data Transport Service (UDTS) to be used for that flow. It is possible that the multiple flows share the same UDTS. 

The RSM-A system defines a fixed set of UDTS: Constant Rate (CR), Constant Rate With Burst (CRWB), Low 
Volume Low Latency (LVLL), High Priority Burst (HPB), Ack Return, and Normal Priority Burst (NPB). Based on 
combination of UDTS and the dynamics like queue size and priority, SDUs are mapped onto different Packet Delivery 
Service (PDS) using either dedicated and/or contention channels at the MAC layer. 

Several "instances" of a single burst UDTS may be available, each instance being independently configurable to provide 
differentiated servicing within the ST. Each UDTS instance is associated with a group of queues within the ST, referred 
to as the "service queue group" of the UDTS instance. In addition, each UDTS instance is associated with a 
configurable parameter "serviceWeight", and each queue in the service queue group shares this parameter. In other 
words, each service queue group is associated with such a weight parameter. Such parameter helps specify the relative 
weighting across the multiple instances of the single burst UDTS. The possible UDTSs and the associated queue 
resources are described below. Note that there are other queues within the ST (other than those mentioned below) that 
are used for carrying internally sourced messages including bandwidth requests, management messages, and address 
resolution requests. All such internally sourced messages are generally queued separately from user data. 

If the MAC receives an SDU with an associated UDTS, for which the mapped PDS (both primary and alternate) does 
not exist, the MAC shall drop the SDU. 

6.3.4.1 Description of UDTS 

6.3.4.1.1 Constant Rate (CR) 

This UDTS offers a constant bit rate service in terms of packets per frame. 

A single instance of the CR UDTS is available. Within this instance, there are multiple queues, one for each connection. 
Classification returns the connection number, which is used to identify the specific queue within the queue group of the 
CR UDTS. 

6.3.4.1 .2 Constant Rate With Burst (CRWB) 

This UDTS offers a minimum bit-rate service with surplus demand being handled using the Bandwidth on Demand 
capability of the system. 

Up to four instances of carriage of the burst portion of CRWB UDTS may be defined. The instances differ in the values 
of the burst threshold and the burst limit applicable to each connection associated with the instance. Each connection 
mapped to a CRWB UDTS instance is queued separately. Classification returns the connection number used to identify 
the specific queue within the queue group of the CRWB UDTS instance, from which the instance can also be 
determined. 

6.3.4.1 .3 High Priority BursVNormal Priority Burst 

The high priority burst and normal priority burst UDTSs use the bandwidth on demand capability of the RSM-A system 
to deliver data. The priority refers to the service priority of the packet. 

Up to four different instances of any combination of HPB and NPB UDTSs may be defined. The different instances of a 
burst UDTS differ among themselves in the relative bandwidth available to each instance. Each instance of a burst 
UDTS is associated with a queue group, with separate queues for traffic destined to each downlink region. 
Classification returns the UDTS instance of the packet, and the Destination MAC Address of the next-hop ST is used to 
determine the destination downlink region and thus the specific queue for the packet. 

6.3.4.1 .4 Low Volume Low Latency (LVLL) 

This UDTS is for use for small transactions where the QoS is primarily determined by the latency of transfer for small 
sets of data. 
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Only one instance of the LVLL UDTS is available, and one queue is used for all LVLL traffic, regardless of the 
destination downlink region of the packets mapped to the LVLL service. Special handling is given to the queue used for 
LVLL. If a packet mapped to LVLL service is received and the LVLL queue is full, the packet is diverted to a 
pre-configured burst UDTS instance. Within the UDTS instance the packet is placed in the specific queue pertaining to 
the destination downlink region of the packet. 

6.3.4.1.5 Ack- Return UDTS 

The envisioned use of the Ack-Return UDTS is for carrying TCP spoofer-sourced PBP acknowledgement packets. One 
instance of the Ack-Return UDTS is available, and in BoD mode one queue is used for all traffic mapped to this UDTS, 
regardless of the destination downlink region of the packets mapped to it. 

In HVUL mode, no special queue for the Ack-Return UDTS is present. Instead, any data mapped to the Ack-Return 
UDTS is treated as belonging to a pre-configured burst UDTS, and placed in the appropriate queue depending on the 
destination downlink region. 

6.3.4.2 Description of PDS 

The RSM-A Air interface defines the following Packet Delivery Services which may be used for packet delivery. 

6.3.4.2.1 High priority rate/Low priority rate 

This refers to the resources associated with a negotiated connection between the ST and the NCC to a particular 
destination ST. A rate PDS is created when a connection is successfully setup. Subsequently, a constant number of slots 
are allocated on an uplink frame by uplink frame basis by the spacecraft. Refer to clause 6.3.3 for details. 

Note that low priority rate is not currently used in the RSM-A system i.e. there is no defined mapping from any UDTS 
to low priority rate. Support for low-priority rate in the ST is optional. 

6.3.4.2.2 High priority volume/Normal priority volume 

These are associated with dynamic resources obtained via the bandwidth on demand protocol with no pre-authorization 
or clearance from the NCC. The BoD protocol is executed frame by frame with the spacecraft which makes allocations 
on a per-uplink frame basis based on the existing demand as reported by the ST. Refer to clause 6.3.3 for details. 

6.3.4.2.3 Slotted Aloha (SA) 

This PDS is associated with certain shared uplink channels on which the ST is permitted to use a slotted aloha protocol 
to transmit individual RSM-A packets. 

6.3.4.2.4 Persistent Aloha (PA) 

This PDS is associated with certain shared uplink channels on which the ST is permitted to execute the Persistent Aloha 
(PA) protocol. There are two types of PA channels. Successful transmission on a PA- Ispnf channel causes the same slot 
number on the same PA channel to be reserved for the ST n uplink frames later, where n = N_ulpc (see clause 8). 
Successful transmission on a PA- 1 spf channel is similar to PA- 1 spnf, where n = 1 . The term PA is used to refer to both 
PA-lspf and PA- Ispnf Where there are specific differences between the two protocols the terms PA- Ispnf and PA- 1 spf 
are used. PA-lspnf is described in clause 6.3.5.3 and PA-lspf is described in clause 6.3.5.4. Note that channels with rate 
equal to 128 kbps shall not be used for PA. 

6.3.4.3 UDTS to PDS mapping 

The mapping of UDTS to PDS follows a basic pattern. For each UDTS, there is a primary PDS (which is used by 
default) and possibly a secondary PDS, which is used if the primary PDS is not available or there is too much 
backlogged demand. Some UDTS may get converted to other UDTS as part of the mapping depending on the 
configuration of the ST and the radio-resources available. Also, under specific conditions, packets marked for a given 
UDTS are allowed to pre-empt Packet Transmission Opportunities (PTOs) which were originally intended to service for 
packets associated with other UDTS. 

The following clauses detail the UDTS to PDS mapping algorithm. 
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6.3.4.3.1 Constant Rate UDTS mapping 

Constant Rate uses the high priority rate PDS only as the primary PDS. There is no secondary PDS. Constant Rate 
packets are not allowed to pre-empt PTOs from other PDSs. 

For each CR queue an associated parameter called maxQueueDepth is defined. If the arriving packet, if queued, would 
cause the size of the associated constant rate queue to be greater than the maxQueueDepth, the arriving packet is 
discarded. Otherwise it is queued and serviced using high priority rate PDS. 

6.3.4.3.2 High Priority Burst/Normal Priority Burst UDTS mapping 

Burst services are in two priorities, normal and high. Each have associated queues. There are a total of four groups of 
possible queues for a burst UDTS, each with an associated instance id and priority - each queue may be marked either 
as high-priority or as normal priority. Each queue group has an associated weight (serviceWeight) which is used to 
service the queue once the volume PTOs are available. However volume requests are made for the aggregate demand. 

High priority burst is serviced by the high priority volume PDS and normal priority burst is serviced by the normal 
priority volume PDS. If the ST is programmed for HVUL mode, there is only one volume PDS available, which 
services them both. 

It is possible to configure one of the burst queues of an ST to use one slot per frame Persistent Aloha (PAlspf). Note 
that only one queue (to a specific downlink destination region), and not an entire burst UDTS instance may be 
configured to use PAlspf This queue will be serviced using PAlspf PDS if PAlspf is available, and will use volume 
PDS otherwise. 

6.3.4.3.3 Constant Rate with Burst mapping 

CRWB uses the associated connection (as identified by the classifier) for its primary PDS and either the HPV or the 
LPV PDS in BoD Mode or the volume PDS in HVUL mode as its secondary PDS. Whether HPV or LPV PDS is used 
in BoD Mode is decided by configuration. 

For each CRWB queue, there is an associated parameter called the maxQueueDepth. If the new packet would cause the 
queue size to cross the maxQueueDepth, it is dropped. If the new packet does not cause the queue size to cross the 
maxQueueDepth, but does cause it to cross the configured parameter volumeBoDTriggerThreshold, the ST has to 
request volume bandwidth to carry an amount of data equal to the difference between volumeBoDTriggerThreshold and 
the instantaneous queue depth in one or more subsequent volume requests. These parameters are defined in clause 8. 

NOTE: CRWB queues, regardless of the fact that they may be served by two PDSs, are always served in a FIFO 
manner. 

6.3.4.3.4 Low Volume Low Latency mapping 

LVLL uses slotted Aloha PDS as the primary PDS. 

Each LVLL queue has an associated maxQueueDepth. If the queue size crosses the maxQueueDepth, the additional 
packets are serviced using the configured burst service i.e. HPB or NPB by remapping to the queue for the configured 
burst UDTS instance, if allowed by the queue management rules of the appropriate queue. (These remapped packets are 
then serviced based on the burst UDTS to PDS mapping rules). 

If the rate allocation is such that the SA PTOs cannot be used i.e. retuning to the contention channels is not possible, the 
LVLL shall be transmitted by pre-empting the PTOs meant for the rate queue. Volume PTOs shall be used to service 
LVLL packets if the number of volume allocations in a given uplink frame are larger than the number of packets in the 
volume queues - this is known as backfill. Similarly excess rate PTOs may also be backfilled. 

6.3.4.3.5 Ack Return UDTS mapping 

There is one associated queue for the Ack Return UDTS. Ack Return UDTS by default is serviced by PA-lspnf 
Persistent Aloha. If PA-lspnf channels are not available, the Ack-Return queue is serviced just as another LVLL queue. 
Note that in general Ack-Return takes priority over LVLL, and thus when PA is not available, Ack-Return packets are 
preferentially serviced, using any available SA PTOs, over LVLL packets. 
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Table 6.1 : UDTS to PDS mapping table 



UDTS 


PDS 


Rate 


Volume (HPV/LPV) 


SA 


PA 


CR 


Always 


- 


- 


- 


CRWB 


Primary (for data up 
to the burst threshold) 


Secondary (for any excess 
beyond the burst threshold 
but within the burst limit) 






Burst 
(HPB/NPB) 


- 


Always 


- 


- 


LVLL 


Pre-emption allowed 
(when re-tuning to 
contention channel 
not possible) and 
backfill allowed 


Secondary (for any excess 
beyond the queue threshold 
by remapping to a burst 
UDTS instance), pre- 
emption and backfill allowed 


Primary 


Backfill of excess 
PA (PA-lspf or PA- 
lspnf) PTOs 
allowed 


Ack-Return 


Pre-emption allowed 
(when re-tuning to 
contention channel 
not possible and 
backfill allowed if PA- 
1spnf not available) 


Secondary (for any excess 
beyond the queue threshold 
by remapping to a burst 
UDTS instance), pre- 
emption and backfill allowed 
if PA-lspnf not available 


Primary if PA- 
1spnf not 
available 


PA-lspnf Primary 



6.3.4.4 



Management Transport Services (MTS) 



The Management Transport Services (MTS) are offered to packets which are generated by the entities in the ST M- 
plane. Consequently, the MTS are only associated with the SLC-M-SAP; i.e. the management plane service access 
point that the data link layer offers to the local management IP layer. 

Five types of MTS are offered- Very High priority, High priority. Medium priority. Low priority, and Supervisory. 
Very High priority MTS is meant to be used for latency sensitive management protocols, and to this end uses contention 
PDS. High priority. Medium priority and Low priority MTS all use volume PDS, and differ in their queue servicing 
priority and drop-class used. All three are subject to token bucket regulation, unlike Very High priority MTS that is not 
regulated by any token bucket. 

Supervisory MTS uses a separate supervisory SA contention channel for transport. This service is not regulated by any 
token bucket. 

The mapping of MTS to PDS is defined in table 6.2. Note that all MTSs are allowed to backfill user data rate and 
volume assignments. 
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Table 6.2: Mapping of MTS to PDS 



IMTS 


PDS 


Rate 


Volume (HPV/LPV) 


SA 


PA 


Very High 
Priority 


Unrestricted 
pre-emption 


Unrestricted pre-emption 


Primary PDS - not 
subject to management 
bandwidth usage token 
bucket 


Unrestricted 
pre-emption of 
PA-lspfor 
PA-lspnf 


High Priority 


pre-emption 
subject to token 
bucket as below; 
backfill allowed 


Primary PDS 






Medium 
Priority 


pre-emption 
subject to token 
bucket as below; 
backfill allowed 


Primary PDS 






Low Priority 


pre-emption 
subject to token 
bucket as below; 
backfill allowed 


Primary PDS 






Supervisory 






Primary PDS - not 
subject to management 
bandwidth usage token 
bucket; Supervisory SA 
channel used 





6.3.4.5 



Queue servicing and flow control procedures 



6.3.4.5.1 



Servicing of rate queues 



The ST schedules packets from rate based queues with the goal of minimizing the jitter experienced by data in each 
queue. The available rate PTOs should be distributed among all active connections such that each connection 
experiences minimal jitter. 

Each rate PTO is uniquely assigned to a rate queue. If a packet is not available on that queue, the PTO becomes 
available for use by other services. Any service that may use an excess rate PTO may use it. It is also possible for a rate 
PTO to be pre-empted for use by another service, as mentioned previously. 



6.3.4.5.2 



Servicing of volume queues 



Scheduling of burst traffic to use volume PDS is performed with the goal of weighting the volume PTOs among the 
burst queues competing for the same downlink region that have outstanding data. This weighting needs to be respected 
at the time of scheduling burst data. In BoD mode, the available HPV PTOs are allocated to the various queues in the 
following order of priority: 

• First the internal MTS queues are served until the allocation is exhausted. 

• Then the user queues for the burst UDTSs mapped to use HPV PDS (including any CRWB queues exceeding 
their burst threshold) are serviced in proportion of the configured service weights of the UDTS instances, until 
the allocation is exhausted. 

Similarly, the available LPV PTOs are allocated to the various candidate queues (i.e. all queues associated with burst 
UDTS instances configured to use LPV PDS, including any CRWB queues exceeding their burst thresholds) in 
proportion of the configured service weights of the UDTS instances. 

In HVUL mode, the available volume PTOs are allocated to the various queues in the following order of priority: 

• First the internal queues are served (up to the downlink limit) until the allocation is exhausted. 

• Then the LVLL queue is served until the allocation is exhausted. 

• Then the user queues for the burst UDTS are serviced in proportion of the configured service weights of the 
UDTS instances (up to the downlink limits) until the allocation is exhausted. 
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Note that an ST operating in HVUL mode must limit the number of packets scheduled for each downlink region up to 
the downlink limit for the region (excluding LVLL data). 

Any excess volume PTOs may be used by the services that are allowed to do so. It is also possible for a volume PTO to 
be pre-empted for use by another service. 

6.3.4.5.3 Queue servicing regulation procedures 

Usage of PDS by some of the UDTS is limited through certain queue servicing regulation procedures, to impose some 
policy-based constraints on resource usage by the ST. Also, because there are multiple UDTS available simultaneously 
in the ST and common resources are shared between the different UDTS, certain queue servicing procedures are in 
place to prevent one UDTS from constantly pre-empting another kind of UDTS and thus leading to "unfairness" in 
utilization. 

These queue servicing regulation procedures use a token bucket mechanism with the token bucket size and token bucket 
fill-rate being configured by the NCC. The fill-rate is defined in terms of a SatellitePacketRefillSize (SPRS) and a 
RefillTimePeriod (RTP); the ratio SPRS/RTP determines the fill-rate for the token bucket in terms of packets per uplink 
frame. The bucket size is defined in terms of a maxBurstSize. The parameters are defined in clause 8. 

Before servicing a packet a check is performed against the token bucket regulating this servicing. A packet is serviced 
only if the check determines that the packet is conformant. A packet is conformant if sufficient tokens exist in the token 
bucket at the instant when the packet is to be serviced. The number of tokens, A^, in the bucket is updated every RTP 
uplink frames as follows: 

Njjg^ = Min { Ngj^ + SPRS, maxBurstSize} 

One token corresponds to one RSM-A packet, and as many RSM-A packets may be serviced as the number of tokens in 
the bucket. After servicing the queue the number of tokens in the bucket is decremented by the number of packets 
serviced. 

For all but the highPriorityVolume token bucket and the highPlusLowPriorityVolume token bucket (see table 6.3) the 
above discussion applies directly. For the highPriorityVolume and the highPlusLowPriorityVolume token buckets 
(collectively referred to as the volume token buckets) "queue servicing" for purposes of discussion above should be 
interpreted as meaning the process of making BoD requests for queued data. That is to say, volume token buckets are 
consulted at the time of making a BoD request. Only of tokens are available in the applicable token bucket(s), can a 
request be made (of up to the number of packets equivalent to the number of tokens in the bucket(s)). 

Usage of LPV is regulated by the highPlusLowPriorityVolume token bucket. Enough tokens must be available in this 
token bucket for a low priority BoD request of certain size to be made; if not the request size must be limited to the 
number of tokens available in this token bucket. Once a request is made the highPlusLowPriorityVolume token bucket 
must be decremented by size of the request made. Usage of HPV on the other hand is regulated by both volume token 
buckets. Enough tokens must be available separately in each volume token bucket for a high priority BoD request of 
certain size to be made, and if not the request size must be limited to the minimum of tokens available in the two token 
buckets. Note that both token buckets must be decremented when a high priority BoD request is made. 

The different queue servicing decisions that the ST has to take are outlined in the table 6.3. 
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Table 6.3: Token buckets to be used for queue servicing 



TOKEN BUCKET 


USAGE - BoD mode 


USAGE - HVUL mode 


High Priority Volume 


The usage of HPV is limited by this 
token bucket. ST can only make a 
high priority BoD request for upto the 
minimum of the HighPriorityVolume 
token bucket and the 
HighPlusLowPriorityVolume token 
bucket. 


Not applicable 


High Plus Low 
PriorityVolume 


The usage of HPV and LPV is limited 
by this token bucket. ST can only 
make a high priority BoD request for 
upto the minimum of the 
HighPriorityVolume token bucket and 
the HighPlusLowPriorityVolume token 
bucket. ST can only make a low 
priority BoD request if enough tokens 
are available in this token bucket. 


Not applicable 


Data Contention 


The usage of contention PTOs by 
LVLL user data traffic is limited by this 
token bucket. 


Not applicable 


Excess Transmission 


In Bod mode, LVLL PDUs can use 
excess volume and rate PTOs if the 
aggregate generation rate does not 
violate this token bucket as shown 
above. 


In HVUL mode this is applicable 
only to LVLL queues. Excess 
PTOs are any PTO unused by any 
other service. 


Normal Pre-emption 


LVLL PDUs may pre-empt volume 
PTOs as long as the rate at which 
LVLL traffic is generated does not 
violate this token bucket. Note that 
LVLL PDUs may always be 
transmitted in unused volume PTOs. 
Since Ack-Return is treated as an 
LVLL queue when PA is unavailable, 
this token bucket regulates 
pre-emption of volume PTOs by 
Ack-return packets when PA is not 
available. 


Same as BoD mode 


Pre-emption User Traffic For 
Blocked LVLL 


If the ST is currently servicing rate and 
this prevents it from tuning to a 
contention channel, LVLL traffic may 
pre-empt the rate PTOs, as long as 
the rate at which LVLL traffic is 
generated does not violate this token 
bucket. Note that LVLL PDUs may 
always be transmitted in unused rate 
PTOs as discussed in the first item. 
This token bucket also regulates 
pre-emption of rate PTOs by 
Ack-return, when PA is not available. 


If the ST has allocated sufficient 
rate capacity that fewer than 
2 PTOs are available, LVLL traffic 
may pre-empt the rate PTOs, as 
long as the rate at which LVLL 
traffic is generated does not violate 
this token bucket. Note that LVLL 
PDUs may always be transmitted 
in unused rate PTOs as discussed 
in the first item. 


Pre-emption Internal Traffic 
For Blocked Volume 


If the ST is currently servicing only 
rate PDS and additional volume PDS 
is not possible, internal management 
traffic is allowed to pre-empt rate, as 
long as rate at which the internal 
management traffic PDU is generated 
does not violate this token bucket. 


If the ST has allocated sufficient 
rate capacity that fewer than 
2 PTOs are available, internal 
management traffic is allowed to 
pre-empt rate as long as rate at 
which the internal management 
traffic PDU is generated does not 
violate this token bucket. 



6.3.5 Contention channel access procedures 

Contention channels are provided by the network to be used by the STs to transmit small bursts of data or control 
information without first reserving bandwidth through the BoD mechanism. All contention channels are 512 kbps 
carriers for normal operations or 128 kbps carriers for ST-200s in fallback mode. 
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6.3.5.1 



General 



6.3.5.1.1 



Types of access protocols 



The RSM-A system supports three contention access protocols. Table 6.4 describes these three access protocols and the 
corresponding usage of each. Information as to which type of access protocol is used on a given channel is dynamically 
broadcast by the system as part of the TIP, NIP or MIP packet contents. 

Table 6.4: Contention access protocols 



Access Protocol 


Usage 


comments 


Slotted Aloha (SA) 


Shared by all Sis in an uplink cell or 
specific channel groups. Used for BoD, 
management signalling, and user data. 


Similar to standard slotted Aloha. Two 
types of SA channels are defined: 
Supervisory, Data/Control. 


Persistent Aloha one slot per n frames 
(PA-lspnf) 


Shared by all STs in an uplink cell that 
are configured to use PA-1spnf. 


Differs from SA in that successful 
transmission by an ST causes the 
same slot number to be reserved for 
this same ST, n = N_ulpc UL frames 
later. 


Persistent Aloha-one slot per frame 
(PA-lspf) 


Shared by all STs in an uplink cell that 
are configured to use PA-1spf. 


Differs from SA in that successful 
transmission by an ST causes (with 
certain caveats) the same slot number, 
each UL frame thereafter for the next 
N_ulpc UL frames, to be reserved for 
this same ST. 



6.3.5.1.2 



Success or failure indication 



The success or failure of a transmission is indicated in the ULPC packet that is transmitted from the network at every 
uplink frame boundary. If an ST has transmitted a packet in a given slot in a particular uplink frame, the information as 
to whether that packet was received successfully at the satellite or not is given in the ULPC packet sent by the network 
for that uplink frame. This ULPC packet is received at the ST within 6 uplink frames, following the frame of the 
original ST transmission. The packet contains a Reed-Solomon (RS) pass/fail indication for each uplink slot within the 
block decoder subfield as described in clause 7.5.3.2.5. 



6.3.5.1.3 



Retransmission 



The MAC layer shall not perform retransmission of failed packets generated by Bandwidth Control Protocol (BCP). All 
such packet transmission failures are indicated to the BCP. Data SDUs may be retransmitted once, if so enabled, by 
buffering them for potential S A transmission. 



6.3.5.1.4 



Mapping transmission probability to potential contention transmission opportunity 



The slot selection algorithm of each contention access protocol depends on a transmission probability, P. P will always 
belong to the set { 2 ", n e /, m > } and has the meaning given in table 6.5. For Slotted Aloha (SA) channel types, "free 
slot" in table 6.5 refers to a slot for which it is possible to tune to a contention channel without causing an outage to any 
reserved slot that was granted to the ST (including any "seized" Persistent Aloha (PA) slot). For PA channel types, "free 
slot" is further restricted by the set of slots on the selected PA channel that are open for contention (i.e. not "seized" by 
another ST ). "Unconditionally free slot" in table 6.5 refers to a slot for which not only are the above conditions 
satisfied, but also for which it is possible to tune to the contention channel without causing an outage to any potential 
contention transmission opportunity that was already selected for a different contention channel type. "Contention" in 
this table refers indiscriminately to PA, PA-lspf, or any of the SA types; the appropriate contention access protocol type 
and transmission probability variable should be substituted when applying this table to the slot selection algorithm 
section of each particular contention access protocol. The transmission probability variable with respect to SA is P^^ 
(separate values of this variable will be required per SA type supported by the ST). The transmission probability 
variable with respect to either PA or PA-lspf is Pp^. 
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SA-supervisory channel transmissions shall take priority over PA and SA-data/control transmissions; then the ST may 
calculate potential contention transmission opportunities, as applicable, in the following order: PA, then SA- 
data/control. In the event that selected potential contention transmission opportunities of different contention types 
conflict with each other, the ST mat give priority to PA transmission opportunities over SA transmission opportunity. 
Alternatively, ordering may be based on P-values, where a channel type with a smaller P-value takes precedence to a 
channel type with a larger P-value. 

Table 6.5: Transmission probability definition 



P value 


Meaning 


1 


All free slots in the current uplink frame are selected as potential contention 
transmission opportunities. 


1/2(1/4, 1/8, 1/16) 
(P=1/2or1/4 in fallback 
mode on a 128 Kbps 
channel) 


For every 2 (4, 8, 16) consecutive slots of the current uplink frame, if there exists at 
least one free slot in the set of 2 (4, 8, 16) slots, then one potential contention 
transmission opportunity is chosen randomly from the subset of free slots within the set 
of 2 (4, 8, 16) slots. (If the subset of unconditionally free slots is not null, the ST may opt 
to chose randomly from the subset of unconditionally free slots instead. The same 
option applies to all subsequent entries in this table). 


1/32 

(P=1/8 in fallback 

mode on a 128 Kbps 

channel) 


If at least one free slot exists in the current uplink frame, then one potential contention 
transmission opportunity is randomly chosen from the subset of free slots in that frame. 


1/64(1/128, 1/256...) 
(P=1/16, 1/32... in 
fallback mode on a 128 
Kbps channel) 


Either (a) One uplink frame, out of the next 2 (4, 8 ...) frames is chosen as a potential 
frame to contain a contention transmission opportunity. When the reserved slot 
schedule is known for that uplink frame, then if there exists at least one free slot In that 
frame, one potential contention transmission opportunity is randomly chosen from the 
subset of free slots in that frame. 

or (b) with probability 1/2 (1/4, 1/8...) the upcoming uplink frame is chosen as a potential 
frame to contain a potential SA transmission opportunity, in which case, if there exists at 
least one free slot in a frame, then one potential SA transmission opportunity is 
randomly chosen from the subset of free slots in that frame. 



NOTE: P-values are defined in clause 6.3.5.2.6. 



6.3.5.2 



Slotted-Aloha channel access 



The implementation of the SA protocol in the ST shall be such that, while the ST is only transmitting packets on SA 
channels, i.e. during a period wherein the ST has no rate or volume time slot assignments, no time slot or group of time 
slots within the uplink frame shall have higher utilization for SA transmission than any other slot or group of slots with 
the exception of time slot 3 1 . 



6.3.5.2.1 



Types of Slotted Aloha channels 



The RSM-A system supports two types of slotted Aloha channels. Table 6.6 describes these two SA types and the 
corresponding usage of each. Information as to which SA type adheres to a given channel is dynamically broadcast by 
the system, as part of the TIP, MIP, or dynamic contention channel assignment message contents. An ST shall support 
both types of contention channels. 

Table 6.6: Slotted Aloha channel types 



SA Channel Type 


Usage 


Supervisory 
contention channel 


No security check, shared by all Sis in an uplink cell; only for 
management signalling needed as a precursor to getting 
security keys (e.g. registration, authentication, security 
resynchronization requests). 


Data/Control 
contention channel 


Used for bandwidth request messages, management signalling, 
and user data (LVLL traffic). Either (1) shared by all STs in an 
uplink cell ; can be temporary or permanent, or (2) assigned to 
specific channel groups and usable by STs belonging to those 
channel groups only; permanent only. 
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6.3.5.2.2 State machine definitions 

The following definitions are needed to properly interpret the SA State Machine: 

packet: a single packet or a packet couplet that is to be transmitted in a single code block 

buffered for SA transmission: the packet in question is to be transmitted on the next selected SA transmission 
opportunity 

eligible for SA transmission: the packet in question is eligible to be transmitted on a future SA transmission 
opportunity 

buffered for potential SA transmission: same as "eligible for SA transmission" 

6.3.5.2.3 State machine 

The core of the Slotted- Aloha access protocol is illustrated by the state machine in figure 6.1. An ST shall have, at most, 
one instantiation of this state machine per SA type. When a packet is buffered for SA transmission, the ST enters a state 
of waiting for transmission of this packet on the next selected SA transmission opportunity. The SA channel selection 
and slot selection processes are given in the next two clauses. Once the packet is transmitted in the selected SA slot, if 
there are no additional packets buffered for SA transmission, the ST goes back to the idle state, awaiting another packet 
to be buffered for SA transmission. Otherwise, the ST remains in the state of waiting for transmitting the next packet. 

If retransmission is configured and supported by the ST, the SDU shall be buffered for at least 6 frames after initial 
transmission of its last SLC-PDU. If any of the corresponding ULPC status messages indicate that an initial 
transmission for any of the SLC-PDUs for that SDU has failed, then the ST shall enqueue that SDU again for SA 
transmission. Each SDU shall be retransmitted not more than once. If the ST does not receive the ULPC status message 
within 6 uplink frames of the initial transmission of the last SLC-PDU, then the ST should drop the SDU. 



Packet buffered for SA 
transmission 




Packet transmitted in selected 
SA slot and no other packet 
buffered for SA transmission 



Packet transmitted in selected 
SA slot and more packets 
buffered for SA transmission 

Figure 6.1 : State machine for Slotted Aloha 

The "feeder" mechanism by which a packet may be buffered for SA transmission is illustrated in figure 6.2. Each packet 
that is to be potentially transmitted using Slotted Aloha goes through this sequence of events. When a packet arrives 
that is eligible for SA transmission, it is buffered for possible SA transmission. There are a number of factors that may 
prevent this packet from being buffered for transmission in the next selected SA transmission opportunity. Such factors 
are implementation dependent and are outside the scope of the air interface specification. Nonetheless, for illustrative 
purposes, a few examples of possible factors are given below: 

• the packet is enqueued behind another packet of equal or higher priority; 

• the packet is held back until just before the next selected S A transmission opportunity to allow for the potential 
arrival, in the meantime, of a higher priority packet; 

• the ST has exceeded configured S A usage limits defined by number of tokens assigned (specified in units of 
number of packets and uplink frames) for all S A channel types; 

• the packet requires a greater degree of time randomization than is provided by the SA slot selection process. 
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After being buffered for potential SA transmission, two outcomes are possible: 

1) all constraining factors are removed, at which point the packet is buffered for transmission; or 

2) prior to all constraining factors being removed, the packet is cleared from the queue of packets eligible for S A 
transmission. This might happen, for example, if the packet was deleted due to becoming stale prior to being 
buffered for SA transmission or if the packet was transmitted in a non-S A slot prior to being buffered for S A 
transmission. Such events that might cause the packet to be thus cleared are implementation specific and are 
outside the scope of the air interface specification. 



( START ^ 



Packet eligible 
for SA arrives 



Jl 



Packet discarded 

or transmitted non-SA 



Buffer Packet for 

potential SA 

transmission 



All constraining factors 
removed 



\/ 



Buffer Packet for 
SA transmission 



Packet transmitted in 
selected SA slot 



-^ 



Z' STOP ^ 



6.3.5.2.4 



Figure 6.2: Slotted Aloha "Feeder" mechanism 



Mapping transmission probability to potential SA transmission opportunity 



See clause 6.3.5.1.4. The SA slot selection algorithm depends on a transmission probability, P^^. Pg^ will always 
belong to the set { 2 ", n e /, n > } and has the meaning given in table 6.7. "SA" in table 6.7 refers to either of the SA 
types. 



6.3.5.2.5 



Channel selection 



In the event that multiple channels of an SA channel type are offered to the ST, the ST shall randomly choose one 
channel out of the set of possible channels on which to transmit a packet that is being buffered for S A transmission. The 
random choosing of a channel must take place, at the least, every time there is a change to the set of possible channels. 



6.3.5.2.6 



Slot selection 



The selection of potential SA transmission opportunities given a transmission probability was presented above in 
clause 6.3.5.1.4. This clause will give the algorithm by which the slotted- Aloha transmission probability, Pg^, is 

determined for data only, control only and data/control SA channel types. P§^ is a function of two other variables, Pc 

and Pd, and is given by P§^ = min(Pc, Pd) Pc and Pd belonging to the ordered set {Pmax, Pmax/2, Pmax/4...Pmin} 

when operating in normal mode. When operating in fallback mode however, Pg^ is given by 

Pg^ = min[l, 4 x min(Pc, Pd)]. Pmax is a configurable parameter belonging to the set { 2", we {0,1,... 5} }. 

Pmin is a configurable parameter belonging to the set { 2 " , n e {5,6, ... 1 2} } . 

Pc controls the SA transmission probability for a given ST based on the past the history of the SA used by that ST. The 
ST maintains a single value, Pc, per SA channel type without respect to which an SA channel of an S A channel type is 
used during that history: 

• The initial value of Pc is Pmax. 

• Pc can be modified, at most, one time per uplink frame. 
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• For every SA uplink frame transmission failure, the ST must halve Pc within 96 msec, subject to the Pmin 
limit. In this context, "SA frame transmission failure" means that at least one SA packet that was transmitted in 
a frame resulted in a Reed-Solomon fail. 

• For every SA frame transmission success, the ST may double Pc, subject to the Pmax limit. In this context, 
"SA frame transmission success" means that every SA packet that was transmitted in a frame resulted in a 
Reed-Solomon pass. 

• For every max[6, 1/(32 x Pc)] frame that passes without a modification to Pc, the Pc may double Pc, subject to 
the Pmax limit. 

NOTE: The failure/success is detected with the arrival of the ULPC status message at most 6 uplink frames later. 
In the time period between making a transmission and getting the result, the value of Pc is unchanged 
except by other ULPC frames based on previous transmissions. The ST can make multiple transmissions 
per uplink frame; each transmission will be governed by the same value of Pc. 

Pd controls the SA transmission probability for a given ST based on a average loading of the SA. The ST maintains a 
single value of Pd per S A channel type without respect to the history of which channel per S A type the ST tracks over 
time: 

• The loading for a given frame, j, is measured as the number of slots in that frame that have successful 
transmissions in them: Lj=n_success (hence L: assumes integer values from through 32, except when 
operating in fallback mode on a 128 Kbps channel in which case its range varies from through 8). 

• The average loading for a given channel type at any given frame T is given by: L^ = (L"" + Lq)/2 where 

L° is the average loading calculated last time, and Lq is the measured loading of the most recent uplink 
frame for which ULPC status information was received by the ST. 

• When operating in fallback mode on a 128 Kbps channel, the measured loading of the most recent uplink 
frame is scaled up by a factor of 4, before being used in the formula given above for computing L^,. 

• At initialization, when L^°^'^ is unknown, it shall be set to zero in the computation of L^,. 

• The function Pd(L|,) is defined as follows when the contention channel in use is a 512Kbps channel, 
for <= L^ <= 32: 

Pd(0 <= L^ <= 7) = Pmax; 

Pd(7 < L^ <= 11)= 1/32; 

Pd(ll < L^ <= 32)= Pmin. 

For supervisory SA channel type, value of Pg^ is fixed at 1/32 and is not changed irrespective of frame transmission 
success, failure or channel loading. 

6.3.5.3 Persistent Aloha channel access procedure 

6.3.5.3.1 Introduction 

The PA access protocol differs from SA in that successful transmission by an ST on a PA channel causes the same slot 
number, on the same PA channel, to be reserved for the ST in subsequent uplink frames. PA- 1 spnf reserves the same 
slot N_ulpc UL frames later, for this same ST. N_ulpc is a systemwide configurable parameter. Unlike SA, there is no 
supervisory PA channel type. Whereas the S A protocol was designed for rapid transmission of packets of infrequent, 
random, uncorrected arrival, PA was designed for capacity-efficient transmission of infrequent but periodic arrival of 
packets such as TCP ACKs or PBP ACKs. PA-lspf is a separate, although similar, PA protocol. While much of the 
PA- 1 spnf protocol applies to PA-lsplf the differences are described in clause 6.3.5.4. 
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NOTE: The variable N_ulpc defines the number of frames, following a successful transmission on a certain slot 
of a PA-lspnf channel, after which the same slot on the same channel is reserved for the same ST. The 
value of N_ulpc will normally be set longer than the round trip time; thus, the value of N_ulpc should 
allow an ST to learn the status of an earlier transmission on the PA-lspnf channel before the next 
transmission opportunity occurs (i.e. before the potentially reserved PA-lspnf slot occurs). 

By way of introduction, it should be noted that PA-lspnf is used principally to service packets in the Ack-Return UDTS 
queue only. It is possible, however, for excess (unused) PA-lspnf PTOs to be used for servicing other user data packets 
and internal packets. It is also possible for some internal packets to pre-empt PA-lspnf PTOs. Frequently there may be 
conditions under which the PA-lspnf channel may become unavailable. An example is when it is impossible for the ST 
to tune to the PA- 1 spnf contention channel because of other allocations. Whenever PA-lspnf is deemed unavailable, the 
Ack-Return queue is serviced as another LVLL queue. The exact situations that lead to PA-lspnf being marked 
unavailable are given later. 



6.3.5.3.2 



State machine 



The following definitions are needed to properly interpret the PA-lspnf State Machine. 



Term 


Meaning 


Packet 


A single RSM-A packet, or a packet couplet that is to be transmitted in a single code 
block 


Unreserved PA-lspnf slot 


A PA-lspnf slot that is not reserved for any particular ST but rather is available to all 
STs in an UL cell on a contention basis. In particular: slot x of frame y on PA-1spnf 
channel z, where it can be positively identified through a ULPC message that there 
was NOT a successful transmission in slot x of frame y-N ulpc on channel z. 


free PA slot 


A PA-lspnf slot that is both unreserved and does not conflict with a BoD rate/volume 
allocation 






PACTO 


"PA-lspnf contention transmission opportunity - An UL slot, chosen randomly from 
the set of free PA-1 spnf slots, which the ST may use to transmit a packet in 
contention with other STs in the UL cell. 


seized slot 


A PA slot that is reserved for an ST's use due to successful transmission in that slot 
N-ulpc frames previously. IVIore precisely: slot x of frame y on PA-1 spnf channel z, 
where (a) the ST transmitted a packet on slot x of frame y-N_ulpc on channel z and 
(b) received confirmation from an ULPC message, prior to the start of frame y, that 
the transmission in frame y-N ulpc was successful. 


buffered for PA-lspnf 
transmission 


The packet in question is to be transmitted on the PACTO or seized slot 


eligible for PA-lspnf 
contention 


The packet in question is eligible to be transmitted on a future PACTO (see note) 


buffered for potential 
PA-lspnf contention 


Same as "eligible for PA-lspnf contention" 


PA-eligible packet 


Same as "packet eligible for PA-1 spnf contention" 


Burst data 


Connectionless user data and/or control data that that is not eligible for SA 
transmission; bandwidth to service this data is obtained via BoD volume. This 
includes the portion of CRWB data serviced by BoD volume. 


PA-lspnf availability 
evaluation 


The task of performing an evaluation to determine if a PACTO may be scheduled 
over the upcoming PA-lspnf scheduling period. PA-lspnf availability evaluation may 
be periodic with the caveat that PA-lspnf evaluation must be performed at least once 
per uplink frame period. 


PA-lspnf slot retention 
evaluation 


The task of evaluating whether a seized PA slot may be retained or not. PA-1 spnf 
slot retention evaluation must be performed at least once per uplink frame period. 


PA-lspnf scheduling 
period 


The time period (range of slots) over which a PACTO may be scheduled as a result 
of the current availability evaluation of PA-lspnf. The PA-lspnf scheduling period 
specifies the range of slots for which ULPC status is available, and for which it is safe 
to schedule a PACTO such that no conflict with a possible BoD rate/volume 
allocation occurs. 



NOTE: The set of packets that can be transmitted in a PA-lspnf seized slot is broader than the set of packets that 
are eligible for PA- 1 spnf contention and may include non eligible packets such as NULL packets and 
internal packets that can pre-empt the seized PA-lspnf slot. 

The protocol state machine is shown in figure 6.3. 
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PA availability 
evaluation takes place/ 
PA available but no 
PACTO scheduled 



PA availability evaluation 
lakes place; PA not available 



(a) PA slot retention 
evaluation takes 
place and PA 
conditions cease to 
be satisfied; (b) 
tinier expires with 
no packets to 
transmit; null 
unter - N_nulltx 



PA availability 
evaluation takes 
place: PA available, 
PACTO scheduled 
and packet 
transmitted in 
PACTO 



PA slot retention 
evaluation takes 
place and PA 
conditions remain 
I satisfied 




ULPC success 



Timer expires with no 

packets to transmit; 

null counter < 

N_nulltx. NULL packet 

transmitted; null 

counter incremented 



Figure 6.3: Protocol state machine for Persistent Aloha 

The conditions under which the ST attempts to schedule a PA- Ispnf contention transmission opportunity for a 
PA-lspnf -eligible packet are as follows: 

There is no burst data on queue at the ST. 

There are no outstanding BoD volume requests. 

No BoD volume slots have been allocated to the ST during the upcoming BoD cycle. 

The number of consecutive PACTO failures is less than three. 

At least one PA- 1 spnf channel is offered to the ST. 

The average loading, Lf (see below) of at least one PA-lspnf channel that the ST is monitoring is less than a 
configured parameter Lfmax. 

An ST "schedules" a PA-lspnf Contention Transmission opportunity by selecting a range of slots (the PA-lspnf 
scheduling period) and executing the slot-selection algorithm to identify a slot for transmission. The slots have to be 
chosen out of a finite range. The range of slots may be taken across multiple evaluation periods. The range may not 
include any slots that may conflict with a present or future BoD rate/volume allocation. The ULPC status must be 
available for this range. 

Each of the above conditions shall be evaluated at the time of making a PA-lspnf availability evaluation. If any of the 
above conditions is not satisfied, then PA-lspnf is deemed unavailable and the ST shall serve the Ack-Return queue just 
as another LVLL queue (i.e. using SA contention as the primary PDS), until the time of the next PA-lspnf availability 
evaluation. 

On the other hand, if all the conditions above are met at the time of PA-lspnf availability evaluation, the ST shall 
attempt to schedule a PA-lspnf Contention Transmission Opportunity (PACTO) during the upcoming PA scheduling 
period according to rules specified in clause 6.3.5.3.4. 

If, due to probabilistic or deterministic slot-selection factors (see clause 6.3.5.3.4), a PACTO cannot be scheduled 
during the upcoming PA-lspnf scheduling period, then no action is taken until the time of the next PA-lspnf evaluation 
and the rules specified above shall be applied afresh. No state is kept as to what did or did not transpire at the time of 
any previous PA evaluation. 

If, however, a PACTO is scheduled during the upcoming PA-lspnf scheduling period, then the packet is buffered for 
transmission on the PACTO and shall be transmitted irrespective of the above-specified conditions at the instant of 
transmission. 
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Once the packet is transmitted on a PACTO, the ST waits to see if the transmission on the UL was indicated to be a 
success or a failure by the corresponding ULPC packet. 

• If the ULPC packet indicates that the previous transmission failed, or if the ST does not receive and process 
the ULPC packet within N_ulpc frames of the original transmission, then the ST increments the counter for the 
number of successive failures and goes back to idle state. 

• If the ULPC packet indicates that the previous transmission was successful, the ST goes to the "seized" state 
and sets the "number of successive failures" counter to 0. The ST accounts the same slot of the same channel 
N_ulpc frames after the successful transmission to be reserved for its own use. It can transmit a data packet in 
that slot or a NULL packet if there is no data to be sent. Not more than N_nulltx consecutive seized PA-lspnf 
slots can be filled with NULL packets. After this, the ST has to give the slot up if it has no data to transmit. 
The ST cannot transmit a NULL packet if there are data packets waiting to be transmitted. N_nulltx is an ST 
configurable parameter. 

• The ST releases its slot by not transmitting in it. This is broadcast in the next ULPC packet corresponding to 
this frame, and other STs can now use this slot for initial access. 

• After each transmission in a seized slot, the ST goes into a state of "waiting for ULPC in seized". This state is 
analogous to the "waiting for ULPC" state except that the handling of a non-receipt of ULPC packet (within 
N_ulpc frames of the original transmission), i.e. a ULPC timeout is different. In this state a ULPC timeout is 
not considered a failure of transmission unless the number of consecutive ULPC timeouts reaches N_timeout, 
where N_timeout is a configurable parameter. After each success indication, the counter for the number of 
consecutive ULPC timeouts is set to zero and the ST returns to the "seized" state. The only state information 
that is kept from one such cycle to the next is the number of consecutive NULL-packet transmissions so as to 
ensure that this number does not exceed the N_nulltx parameter. On the other hand, if any ULPC indicated a 
failure or if the counter of consecutive ULPC timeouts reaches N_timeout, the ST sets the counter to zero, 
releases the seized slot and returns to the IDLE state. However, the "number of successive failures" counter 
shall not be incremented. 

While in the "seized" state or the states of "Waiting for ULPC," the ST continues to ensure, at least once every frame, 
that the following conditions continue to be satisfied: 

• The PA-lspnf channel on which the ST transmitted remains in the set of PA-lspnf channels offered to the ST 
(i.e. via a channel information element of a MIP). 

• The seized PA-lspnf slot does not conflict with a BoD rate/volume slot allocated to the ST. 

These conditions constitute the PA-lspnf slot retention evaluation. If any of these conditions ceases to be satisfied while 
waiting for pass/fail indication or while in the "seized" state, the ST goes back to the Idle state. The ST must release the 
seized slot at the same time. 

6.3.5.3.3 Channel selection 

In the event that multiple PA- 1 spnf channels are offered to the ST, the ST shall randomly choose at least one channel 
out of the set of possible channels on which to monitor ULPC messages and attempt to schedule a PACTO. When 
PA-lspnf is in the Idle state, then the random choosing of a channel must take place, at the least, every time there is a 
change to the set of possible channels. For all other states, the ST need not re-randomize as long as the channel the ST 
has been monitoring, or on which it is transmitting, remains in the set of PA-lspnf channels made available to the ST. 
In the event that a PA-lspnf channel is removed from PA-lspnf service, and an ST has either seized or is awaiting 
seizure of a slot on that channel, the ST shall return to the IDLE state. 

Whichever PA-lspnf channel(s) the ST chooses to monitor, the ST shall continuously monitor the ULPC packets for 
that channel(s) while in the IDLE state; otherwise, when a PA-lspnf -eligible packet arrives at the ST, the ST would 
have to wait potentially several frames before successfully scheduling a PACTO. 

6.3.5.3.4 Slot selection algorithm for PACTO 

An ST attempts to schedule a PACTO only under the conditions outlined in clause 6.3.5.3.2. The period of time covered 
by the scheduling attempt is the upcoming PA-lspnf scheduling period. 
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In order to attempt to schedule a PACTO, the ST must first know the loading on the PA-lspnf channel(s) as determined 
by ULPC packets. These packets are used for two purposes in scheduling a PACTO. First, these packets are used to 
determine the probability of scheduling a PACTO or even if the channel is available for PA-lspnf For this purpose, 
ULPC packets are evaluated on a UL-frame-by-UL-frame basis. This will be described in more detail below. 

Second, ULPC packets are monitored to determine which slots of a particular PA channel are unreserved (and therefore 
can be used as a potential PACTO) during the upcoming PA-lspnf scheduling period. 

The ST maintains the last N_ulpc ULPC packets successfully received by it. The ULPC information is stored associated 
with the frame number and the channel number to which is corresponds. It is possible that this ULPC history be 
discontinuous since ULPC packets may be lost or dropped. The way ULPC information is used for scheduling a 
PACTO is described below. 

In particular, let the upcoming PA-lspnf scheduling period span slot x of UL frame M to slot y of UL frame M. Then 
the set of unreserved slots from which a PACTO is potentially chosen is the set of slots for which ULPC did indicate an 
R/S fail in the span of slot x of frame M-N_ulpc through slot y of frame M-N_ulpc for the channel under consideration. 
If R/S pass/fail cannot be discerned for any portion of this span (e.g. a ULPC packet was not received or monitored, for 
the channel under consideration) then the ST must exclude those slots from the potential set of unreserved slots. The set 
of free PA-lspnf slots is the subset of unreserved PA-lspnf slots that does not conflict with a BoD rate/volume 
allocation that was granted to the ST. 

Once the set of free PA-lspnf slots is known and the probability, Pp^, of scheduling a PACTO is known (see below), 
then the attempt to schedule a PACTO shall take place in the following manner: 

• Let X be the total number of slots in the upcoming PA-lspnf scheduling period; let z be the PA-lspnf channel 
on which the ST will attempt to schedule a PACTO. 



• 



• 



With probability min(l,X x Pp^^) let the upcoming PA-lspnf scheduling period be chosen to contain a 
PACTO. 

If the upcoming PA-lspnf scheduling period was chosen to contain a PACTO and the set of free PA-lspnf 
slots on channel z is not NULL, then randomly choose one free PA- 1 spnf slot from the set of free PA slots on 
channel z to be the PACTO for the upcoming PA-lspnf scheduling period, else return to the "wait for 
PA-lspnf evaluation" state to await the next PA-lspnf evaluation time. 

The PA probability, Pp^, is a function of two other variables, Pe and Pf, and is given by Pp^ = min(Pe, Pf). Pe and Pf 
are bounded by Pemin and Pemax, the values of which are defined in table 6.7. 

Pe controls the PA-lspnf transmission probability for a given ST based on past history of PA-lspnf used by that ST. 
The ST maintains a single value of Pe without respect to which PA-lspnf channel is used during that history. Pe is set at 
initialization to Pemax. 

• If the number of consecutive failures is then Pe=Pemax. 

• If the number of consecutive failures is 1 or 2 then Pe=Pemin. 

• If the number of consecutive failures is 3, then Pe is not applicable; the PA-lspnf conditions are not satisfied 
and the ST shall serve the PA- 1 spnf -eligible queue as an LVLL queue. 

• ST shall decrement the "number of consecutive failures" counter if at least 20 frames passes without a 
transmission in a PACTO until that counter reaches 0. 

Pf controls the PA-lspnf transmission probability for a given ST based on a average loading, L^, of PA-lspnf The ST 
maintains a single value of Pf without regard to the PA-lspnf channel that it is monitoring. 

The loading for a given frame, j, is measured as the number of slots in that frame that have successful transmissions in 
them: Lj=n_success: 

• The average loading at any given frame T is given by: Lr=(Lfi- -I- Lg ) / 2, where L"^ is the average 

loading calculated last time, and Lg is the measured loading of the most recent frame for which ULPC status 
information was received by the ST. 
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• At initialization, for the purposes of channel loading computation, L^"'*^ is assumed to be zero, subject to the 

condition that if the resultant value is less than 0,7 x Lfmax, then Lf shall be reset to a value in the range 
0,7 X Lfmax<=Lf<=Lfmax. 

• The function Pf(Lj) is as follows: 

For L^0,7 X Lfmax Pf=Pfmax; 

For 0,7 X Lfmax <= L^ < Lfmax Pf=Pfmin; 

For Lf >= Lfmax Pf is not applicable; PA-lspnf is unavailable. 

6.3.5.4 Persistent Aloha channel access procedure-one slot per frame 

6.3.5.4.1 Introduction 

One-slot-per-frame PA-lspf is a contention access protocol that may be offered by the RSM-A system in addition to 
regular PA-lspnf. That is, the protocol is supported by the RSM-A system, but PA-lspf channels will be offered in a 
UL cell only if there is sufficient demand to warrant allocating UL bandwidth to PA-lspf. Whereas PA-lspnf was 
designed for capacity-efficient transmission of infrequent but periodic arrival of packets such as PBP ACKs (from 
spoofed TCP connection), PA-lspf was designed for capacity-efficient transmission of more frequent quasiperiodic 
arrival of packets such as TCP ACKs from nonspoofed TCP connections. 

PA- 1 spf is similar to PA- 1 spnf in that once the first contention transmission is successful, further transmission slots are 
reserved for, or "seized" by, the ST by virtue of the previous successful transmission. PA- 1 spf differs from PA-lspnf in 
that once an ST seizes a slot position in a UL frame, that slot position is reserved for the ST in all subsequent frames, 
not just once every N_ulpc frames as in the PA-lspnf case, until the ST releases the slot. 

PA-lspnf and PA-lspf cannot be active simultaneously in an ST. If an ST supports both the PA-lspnf and PA-lspf 
protocols, and data is present that is eligible to use either protocol, it is up to the discretion of the ST to determine which 
protocol takes precedence over the other. However, if data is present that is eligible for PA-lspf but not eligible for 
PA-lspnf, then, according to the conditions of clause 6.3.5.3, PA cannot be active. The reverse does not hold true (the 
presence of data that is PA-lspnf -eligible but is not PA-lspf-eligible does not inhibit the use of PA-lspf). 

The protocol description of PA-lspf is almost identical to that of PA-lspnf. Only the differences between the two 
protocols are given below: 

NOTE: All configurable parameters are independent between PA-lspnf and PA-lspf except for N_ulpc. 

6.3.5.4.2 state machine 

All of the state machine definitions for PA- 1 spf are identical to those for the PA- 1 spnf State Machine except for the 
following: 

unreserved PA-lspf slot: An ST shall declare a slot x of frame y on PA-lspf channel z unreserved if and only if all 
slots X in frames y-N_ulpc through y-1, inclusive, are unreserved. 

seized slot: A PA-lspf slot that is reserved for an ST's use due to successful transmission in that slot on a previous 
frame (as detailed below). More precisely, slot x of frame y on PA-1 spf channel z, where, in the event that the last 
transmission was on a PACTO, (a) the ST transmitted a packet on slot x of frame y-N_ulpc on channel z and (b) 
received confirmation from an ULPC message, prior to the start of frame y that the transmission in frame y-N_ulpc was 
successful; or where, subsequent to seizing a slot, (a) the ST transmitted a packet on slot x of frame y-1 on channel z 
and (b) in the event that the ST transmitted a packet on slot x of frame y-N_ulpc, the ST received confirmation from an 
ULPC message, prior to the start of frame y that the transmission in frame y-N_ulpc was successful. The ST shall not 
consider a slot as seized if a ULPC status message is not received for any of the preceding N_ulpc -1 frames. 

eligible for PA-lspf contention: The packet in question is eligible to be transmitted on a future PACTO (note that the 
set of packets that can be transmitted in a PA-lspf seized slot is broader than the set of packets that are eligible for 
PA- 1 spf contention and may include non eligible packets such as NULL packets and PA-eligible and SA-eligible 
control or user packets that can pre-empt the seized PA-lspf slot). 

The protocol state machine is shown in figure 6.3. 
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The conditions under which the ST attempts to schedule a PA- Ispf contention transmission opportunity for a 
PA-lspf-eHgible packet rather than make a BoD request are identical to those for PA- Ispnf eligibility. 

Once the packet is transmitted on a PA- 1 spf channel PACTO, the ST shall wait to receive the R/S pass/fail indication 
on the corresponding ULPC packet. 



• 



• 



If the ULPC packet indicates that the previous transmission failed, or if the ST does not receive and process 
the ULPC packet within N_ulpc_frames of the original transmission, then the ST increments the counter for 
the number of successful failures and goes back to idle state. 

The ST shall monitor the ULPC messages for frame yH-l-N_ulpc through frame y-1. If a successful 
transmission was indicated for slot x of channel z of any frame in this range of frames, then the ST must go 
back to the IDLE state after processing the ULPC message for frame y, even if the ULPC for frame y indicated 
its own transmission was successful. In addition, the counter for the number of successive failures is 
incremented. 

If the ULPC packet indicates that the previous transmission was successful, and no successful transmissions 
were indicated for frame yH-l-N_ulpc through frame y-1, the ST goes to the "seized" state and sets the "number 
of successive failures" counter to 0. The ST accounts the same slot of the same channel N_ulpc frames after 
the successful PACTO transmission, and each subsequent frame thereafter, to be reserved for its own use. It 
can transmit a data packet in that slot or a NULL packet if there is no data to be sent. Not more than 
N_lspf_nulltx consecutive seized PA-lspf slots can be filled with NULL packets. After this, the ST has to 
give the slot up if it has no data to transmit. The ST cannot transmit a NULL packet if there are data packets 
waiting to be transmitted. N_lspf_nulltx is an ST configurable parameter. 

The ST releases its slot by not transmitting in it. This is broadcast in the next ULPC packet corresponding to 
this frame and other STs can now use this slot for initial access. 

• For the first N_ulpc-1 transmissions in a seized slot, the ST remains in the seized state without transitioning to 
the "Wait for ULPC" state. This is due to the fact that any ULPC for frames y-nl through Y-lH-N_ulpc has no 
bearing on this ST. After each subsequent transmission in a seized slot of frame ynew, the ST goes back into a 
state of waiting for the ULPC packet of frame ynewH-l-N_ulpc. After each success indication, the ST returns 
to the "seized" state. The only state information that is kept from one such cycle to the next is the number of 
consecutive NULL -packet transmissions so as to ensure that this number does not exceed the N_lspf_nulltx 
parameter. On the other hand, if any ULPC indicated a failure or if the ULPC packet for frame 
ynewH-l-N_ulpc is not received by the start of frame ynewH-1, the ST releases the seized slot and returns to the 
IDLE state. However, the "number of successive failures" counter does not need to be incremented. 

While in the "seized" state or the state of "Waiting for ULPC," the ST shall continue to ensure, at least once every BoD 
cycle, that the same conditions continue to be satisfied as per the PA- Ispnf protocol. 

6.3.5.4.3 Channel selection 

In the event that multiple PA-lspf channels are offered to the ST, the ST shall randomly choose at least one channel out 
of the set of possible channels on which to monitor ULPC messages and attempt to schedule a PACTO. The same rules 
apply as those listed for the PA- Ispnf protocol in clause 6.3.5.3.3. 

6.3.5.4.4 Slot selection algorithm for PACTO 

Except for the definition of an unreserved PA-lspf slot, the slot selection algorithm is identical to that for the PA- Ispnf 
protocol as described in clause 6.3.5.3.4. 
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6.3.5.5 



Variables 



Table 6.7: Variables for contention channel access 



Variable 


Purpose 


Computed/Updated 


PsA''PpA^ PpAlspf 


To control the transmission probability for a 
given ST in a given channel for any available 
slot, using SA/PA-1spnf/PA-1spf 


min(Pc, Pd) / min(Pe, Pf) / min(Pb, Pg) 


Pc 


To control the transmission probability for a 
given ST in a given SA channel for any 
available slot based on past history 


IVIaintained by ST. Value is between Pmin 
and Pmax, divided by 2, for failure. 
IVIultiplied by 2 for success or for passage of 
time 


Pe/Pb 


To control the transmission probability for a 
given ST in a given SA/PA-1 spnf / PA-1 spf 
channel for any available slot 


IVIaintained by ST. Value is between 
Pemin/Pbmin and Pemax/Pbmax, set to 
min for failure; set to max for success or for 
passage of time 


Pd / Pf / Pg 


To control the transmission probability for a 
given ST in a given SA/PA-1 spnf / PA-1 spf 
channel for any available slot based on 
loading 


IVIaintained by ST. Computed as a function 
of a weighted moving average load, 
Ld/Lf/Lg, over the last N_ulpc frames 


Pmax / Pemax / 
Pbmax / Pfmax 


To bound the maximum transmission 
probability for SA/PA-1 spnf / PA-1 spf 


Configured(dynamically via System Profile 
MIP)/ (1/32)/ (1/32)/ (1/32) 


Pmin / Pemin / 
Pbmin/ Pfmin 


To bound the minimum transmission 
probability for SA/PA-1 spnf / PA-1 spf 


Configured(dynamically via System Profile 
MIP)/ (1/256)/ (1/256)/ (1/256) 


Lfmax/ Lgmax 


To cause a PA-lspnf /PA-1 spf channel to be 
unavailable to an ST if the weighted average 
loading on that channel is too high 


Configured (statically via DLL mechanism) 



6.3.6 Packet filtering procedures 



6.3.6.1 



Packet discrimination procedure 



STs shall receive all the data transmitted in the microcell to which it belongs. A ST is assigned a unique RSM-A 
Destination MAC Address for each virtual port and management port (within the satellite network), on which it shall be 
capable of receiving dedicated traffic. STs shall also be capable of receiving system multicast and user multicast 
information. These are identified by well-defmed MOID numbers. The ST has to receive and interpret all messages 
which are addressed using the well defined MGIDs. For all packets, if the frame header is present, and the application 
ID indicates the TP diag function, then the normal delivery is overridden, and the packet is delivered instead to the TP 
diag function. 

The ST identification field defined in clause 7.3.2 is used to identify multicast as well as unicast user data and signalling 
traffic to a ST. 

See the figure 6.4, Packet filtering tree, for a flowchart of the discrimination procedure. 
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Figure 6.4: Packet filtering tree 



Data packets 



The Data packets addressed to a ST may be either user data (which may be multicast or unicast) or ST management 
data. 



6.3.6.1.2 



Signalling packets 



SignalHng packets, like Transmission information packet, ULPC Status packet etc are multicast in the cell and are 
identified by reserved Multicast Group IDs (MGID), refer to clause 7.5 for the list of all the signalling packets. 
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Message functional definition and contents 



7.1 



General 



7.1.1 Packet order of presentation 

The order of presentation or transmission of both upUnk and downlink RSM-A packets by the STs is in consecutive 
byte number, starting with byte (header) and ending with byte 107. The STs transmit order of presentation of the bits 
within each byte of a packet is MSB first (bit 7) and LSB last (bit 0). The packets are transmitted in order as shown by 
the direction of transmission in figure 7.1. 



ByteO 



(MSB) (LSB)I(MSB) 



Byte 1 Byte 2 

(LSB)I(MSB) (LSB) 



Byte 107 
(MSB) (LSB) 



Time ■ 



Figure 7.1 : Packet byte and bit order of presentation 

7.1.2 Order of bits within a field 

The order of bits within a field shall be "big-endian" as illustrated in figure 7.2. 
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Figure 7.2: Order of bits within a field 



7.2 



MAC block format 



7.2.1 



MAC downlink block format 



A downlink MAC block consists of two RSM-A packets as shown in figure 7.3. 
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Figure 7.3: Downlink IVIAC blocit format 

Each RSM-A packet consists of a MAC RSM-A packet header and an SLC-PDU. The MAC packet header is described 
in clause 7.3. 

7.2.2 MAC uplink block format 

An uplink MAC block consists of two RSM-A packets. Plus an Access Control Field (ACF). 
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Packet 
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Figure 7.4 : Uplink MAC block format 

Each RSM-A packet consists of a MAC RSM-A packet header and an SLC-PDU. The MAC packet header is described 
in clause 7.3. 

During block assembly, the MAC shall request an ACF from the SAM as specified in BSM RSM-A interface 
specification, SMAC/SLC layer, TS 102 189-3 [7]. 

If at the time of transmission opportunity, there is only one RSM-A packet to transmit, the ST shall complete the MAC 
block using a NULL packet for packet 1. The NULL packet format is described in clause 7.4.7. 

7.3 Packet header format 

The RSM-A packet header consists of 2 parts, the Satellite Routing Field and the ST Identification Field, as shown in 
figure 7.5. 
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Figure 7.5: RSM-A packet header format 



7.3.1 Satellite routing field 



The first 2 bytes of the packet structure shown in figure 7.6. Satellite Routing Field Format is used to indicate to the 
satellite payload the destination where the packet is to be routed. 
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Downlink Destination ID (LSB) 


1 



Figure 7.6: Satellite routing field format 

The satellite payload may modify the Satellite Routing Field when it delivers ST generated packet to the downlink 
(either spot or shaped beams). If the Destination Type sub-field specifies Multicast Replication Group, the Payload 
replaces all of the Satellite Routing Field sub-fields (except the Drop Class and Dest Type sub-fields) with values 
configured for the specified Multicast Replication Group for each copy of the packet forwarded. Each copy of the 
packet contains the original Drop Class sub-fields, ST Identification field, and Data Payload fields. 

7.3.1.1 Congestion bit field 

On the uplink, the ST shall set this bit to "0". 

On the downlink, the congestion bit is set to 1 to indicate that there is congestion in the downlink microcell for the 
specific polarity in which the message is being received. 

Table 7.1 : Congestion bit field 



Link 


Byte 0, Bit ? 


Description 


Uplink 





Sub-field not used 


Downlink 


N/A 


This field is ignored for all MAC messages 


Downlink 





No congestion 


Downlink 


1 


Congestion (queue exceeds a pre-configured congestion threshold) 



7.3.1.2 



Drop class field 



The Drop Class sub-field is set by the packet originator (e.g. STs or satellite) and used by the network. Drop class 
ranges from to 3. "0" is the highest priority and, thus, has the least chance of being dropped by the network. All MAC 
messages shall use drop class "0". 

Table 7.2: Drop class field values 



ByteO, 
Bite 


ByteO, 
Bits 


Description 








Drop class 





1 


Drop class 1 


1 





Drop class 2 


1 


1 


Drop class 3 
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7.3.1.3 



Destination type field 



The Destination Type sub-field is set (table 7.3) by the STs for specifying uplink packet type, downlink transmission 
mode, or uplink destination. The uplink packet type option is null packet. The downlink transmission mode options are 
spot beam, shaped beam, or multicast. The CONUS broadcast beam is only one of the possible shaped beam patterns. 
The uplink destination option is the network. 

The ST originated null packets and network packets are terminated by the network and do not get forwarded to 
downlink. The ST originated multicast replication group packets are terminated by the network and cause the creation 
of multiple "replicated" packets on the downlink. 

The Destination Type field is set (table 7.3) by the network for network generated packets. It specifies downlink packet 
type or downlink transmission mode. The downlink packet type option is null packet or replicated packet, and the 
downlink transmission mode options are spot beam, cellcast, or shaped beam. 

If an ST receives a packet with destination type subfield binary value of 00 or 11 then the ST shall drop the packet. 

Table 7.3: Destination type field values 



ByteO, 
Bit 4 


ByteO, 
Bits 


ST originated packet description 


Network originated packet description 








Null Packet 


Null Packet 





1 


Spot or Shaped Beam 


Spot, Cellcast, or Shaped Beam 


1 





Multicast Replication Group 


Replicated by the Network 


1 


1 


Network 


Not Used 



7.3.1.4 



Downlink destination ID field 



The interpretation of the Downlink Destination ID field is conditioned on the value of the Destination Type field. Refer 
also to TS 102 188-6 [4]. 

If the destination type field is "00" then the downlink destination ID is encoded as all zeros. 

If the Destination Type field is encoded as "01", then the Downlink Destination ID field shall be as defined in 
TS 102 188-6 [4]. 

The ST shall filter, based upon downlink destination IDs the ST is configured to accept, all received packets bearing a 
destination type sub-field specifying either "spot/cellcast/shaped beam" or "replicated by network". The satellite shall 
discard any packet received with both a destination type sub-field specifying "spot/cellcast/shaped beam" and a cell 
number sub-field specifying a reserved value. 

Figure 7.7: Void 

Table 7.4: Void 

On the uplink, if the Destination Type field is encoded as "10", the Downlink Destination ID field specifies the 
Multicast Replication Group Number (0-511) that the network uses to replicate the packet. All other values are 
reserved. 

On the downlink, if the Destination Type field is encoded as "10", then the Downlink Destination ID field is as defined 
inTS 102 188-6 [4]. 

If the Destination Type field is encoded as "11", the network consumes the packet. The packet type is further defined by 
the Downlink Destination ID fields as shown in table 7.5. 

Table 7.5: Cell number field values 



Cell Number 
Sub-field 


Description 





NOCC to network signalling (not used by STs) 


512 


Bandwidth request message from ST to network 


All other values 


Reserved 
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7.3.2 ST Identification field 

Bytes 2 through 7 of the packet structure contain terminal address information as shown in figure 7.8. 
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Figure 7.8: ST Identification field format 



7.3.2.1 



Destination Sub-Address field 



If the three high-order bits of the Destination Sub-Address field (the Mcst sub-field) are zero, the remaining 18 bits of 
the Destination Sub-Address field represent a Multicast Group Number. Otherwise, the Destination Sub-Address is the 
address of an ST, an ST port or the network. The Destination Sub-Address of an ST or an ST port is only unique within 
a specific downlink microcell and its polarisation. 

The Multicast Group Number is unique system-wide. Table 7.6 shows the Multicast Group Number assignments. The 
first 39 332 values are reserved for internal system use. The NCC dynamically assigns and releases the remaining group 
numbers as requested for user multicasts. Note that user multicasts may use the network's multicast replication, shaped 
beam, both, or neither. 

Table 7.6: Multicast group number assignments 



Multicast group 
number 


Description 


0to127 


Internal system use for Transmission Information packet 
messages (see note) 


1 28 to 255 


Internal system use for ULPC Status messages (see note) 


256 to 383 


Internal system use for Uplink Indirect Management 
Information packet messages (see note) 


384 to 51 1 


Internal system use for Bandwidth Assignment messages 
(see note) 


51 2 to 639 


Internal system use for Dynamic Contention channel 
assignment messages (see note) 


640 to 767 


Internal system use for negative acknowledgement 
messages (see note) 


768 


Reserved for Internal system use 


769 


Internal system use for NCC Services 


769 


Internal system use for NCC Routing 


769 


Internal system use for ST State 


769 


Internal system use for BC Congestion 


769 


Internal system use for BOD/HVUL Region Mapping 


769 


Internal system use for DAMR Information 


769 


Internal system use for System Profile 


769 


Internal system use for ST Registration 


769 


Internal system use for Channel Information 


769 


Internal system use for DPC 


769 


Internal system use for DLL Announcement 


769 


General Use (all other purposes addressed to all STs 
without advance configuration) 


770 


Internal system use for Registration Traffic 


771 to 920 


Internal system use for DLL Range (Configuration and 
Operational Software DLL) 


921 


Internal system use for HVUL 


922 


Internal system use for PIM-SIM 


923 


Internal system use for Congestion Testing 


924 to 1 023 


System Reserve (Spare) 


1 024 to 1055 


Internal system use for SSTs (Management and DPC) 


1 056 to 8 000 


Internal system use for NSP/BBS ST Management 
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Multicast group 
number 


Description 


8 001 


Internal system use for Commissioning software DLL 


8 002 


Internal system use for Shaped Beam Availability test 


8 003 


Internal system use for Over the Air IDU Replacement 


8 004 to 39 332 


System Reserve (Spare) 


39 333 


Dynamically assigned to users 




Dynamically assigned to users 


218 to 1 


Dynamically assigned to users 


NOTE: The ST shall filter these MGIDs with the cellcast/microcast logic specified 
below. 



For multicast group numbers from to 767 the lower 7-bits of the multicast group number can be used to signify which 
of the microcells per uplink cell are sent system information packets in cellcast or microcast modes. A value of X=0 
signifies that the system information packet is sent in cellcast mode only. A value of X=l signifies that the system 
information packet is sent in microcast mode. 

Microcell #7 (center microcell) shall never use cellcast and microcast at the same time, only one or the other. For 
microcells #1 to #6, more than one microcell may use microcast packets at the same time. The microcell numbering is 
defined in BSM RSM-A TS 102 188-1 [1]. 

The lower 7-bits in of the multicast group number in packet header bytes 2 to 4 have the following meaning: 

1111111= All STs must process microcast system information packets. 

XXXXXXl = Microcell #1 STs must process microcast system information packets. 

XXXXXIX = Microcell #2 STs must process microcast system information packets. 

XXXXIXX = Microcell #3 STs must process microcast system information packets. 

XXXIXXX = Microcell #4 STs must process microcast system information packets. 

XXIXXXX = Microcell #5 STs must process microcast system information packets. 

XIXXXXX = Microcell #6 STs must process microcast system information packets. 

IXXXXXX = Microcell #7 STs must process microcast system information packets. 

0000000 = Microcell #0 or all STs within the uplink cell must process cellcast system information 
packets. 

XXXXXXO = Microcell #1 STs must process cellcast system information packets. 

XXXXXOX = Microcell #2 STs must process cellcast system information packets. 

XXXXOXX = Microcell #3 STs must process cellcast system information packets. 

XXXOXXX = Microcell #4 STs must process cellcast system information packets. 

XXOXXXX = Microcell #5 STs must process cellcast system information packets. 

XOXXXXX = Microcell #6 STs must process cellcast system information packets. 

OXXXXXX = Microcell #7 STs must process cellcast system information packets. 



7.3.2.2 



Aloha field 



The Aloha field is a bit that indicates whether the uplink packet is being sent in an Aloha (contention) slot ("1") or in an 
assigned rate/volume slot ("0") according to table 7.7. This bit is only defined in the uplink. This bit is "do not care" in 
the downlink and should be left in its uplink state or set to zero for packets generated by the network. The exception is 
that for uplink and downlink null packets, the Aloha bit is set to "1". 



£75/ 



62 



ETSI TS 102 189-2 VI. 1.1 (2004-03) 



Table 7.7: Aloha field 



Link 


Byte 4, 
Bit 2 


Description 


Uplink 





Rate or volume channel 




1 


Contention channel 




1 


Null packets 


Downlink 


X 


ST originated packets 







Network originated packets 




1 


Null packet 



7.3.2.3 SLC mode field 

The SLC mode field is a 2-bit field that indicates the SLC mode (see table 7.8). 

If an ST receives a packet with an SLC mode field set to a mode which it does not support then it shall drop the packet. 

Table 7.8: SLC mode field values 



Bit 


Description 


00 


Transparent 


01 


SLC header present - unacknowledged mode 


10 


Reserved for Network 


11 


spare 



7.3.2.4 



Source ID field 



The Source ID field always identifies the sending ST or network (table 7.9) uniquely systemwide. Note that the Source 
ID is a "flat" identifier that does not correspond to the address that would be used to send a data packet to this ST. The 
purpose of the Source ID is to authoritatively identify the sending entity for billing and monitoring purposes. However, 
a receiving ST may use this field to identify the source for the purpose of associating the incoming packet with a current 
Segmentation and Reassembly (SAR), compression, or ST-to-ST link protocol state. 

Table 7.9: Reserved source ID values 



ID (hex) 


Description 


000000 - 00003F 


Reserved for network 


000040 


Reserved for registration messages 


1FFFF0 


Reserved for transmission information 
packet and ULPC status messages 


1FFFF0-1FFFFF 


Reserved for satellite sourced messages 



7.4 SLC packet data unit format 

The ST shall build 100 byte SLC-PDUs as per clause 5. 

7.4.1 SLC unack mocJe header format 

The SLC in unacked mode uses four different header formats for data transmission. The header format used for 
transmission depends on the length of the data packet and the packet type being transmitted. Each header format is 
described below. A data packet that meets the segmentation criteria is fragmented. Segmentation Criteria are defined in 
clause 5.6. 

The four packet types are: 

• unfragmented (Whole) data packet; 

• first segment of fragmented data packet; 
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• middle segment of fragmented data packet; 

• last segment fragmented data of packet. 

An ST shall only include SLC extension headers, frame headers and security headers on unfragmented data packets and 
first segment of fragmented data packet. 

7.4.1 .1 Header for unfragmented (whole) data packet 

The header for unfragmented data packet (figure 7.9) consists of the following fields. 



(MSB) 
Bit? 


Bite 


Bits 


Bit 4 


Bits 


Bit 2 


Biti 


(LSB) 
BitO 


Byte 


Session Number 


First 


Last 





Packet Sequence Number 


1 


Cmp Frm Sec CRC Type Spare E 


2 


Bytes in Last Segment 


3 



Figure 7.9: Header for unfragmented packet 

7.4.1 .2 Header for first segment data packet 

The header for first segment of data packet consists of the following fields. 



(MSB) 
Bit? 


Bite 


Bits 


Bit 4 


Bit 3 


Bit 2 


Biti 


(LSB) 
BitO 


Byte 


Session Number 


First 


Last 





Pacl<et Sequence Number 


1 


Cmp 


Frm 


Sec 1 CRC Type | Spare 


E 


2 



Figure 7.10: Header for first segment data packet 

7.4.1 .3 Header for middle segment data packet 

The header for middle segment data packet consists of the following fields. 



(MSB) 
Bit? 


Bite 


Bits 


Bit 4 


Bit 3 


Bit 2 


Biti 


(LSB) 
BitO 


Byte 


Session Number 


First 


Last 





Pacl<et Sequence Number 


1 



Figure 7.1 1 : Header "middle" segment 

The Sending ST uses this packet type when sending the middle segment of a fragmented user data packet to the 
Receiving ST. 

7.4.1 .4 Header for last segment data packet 

The header for last segment data packet consists of the following fields. 



(MSB) 
Bit? 


Bite 


Bits 


Bit 4 


Bit 3 


Bit 2 


Biti 


(LSB) 
BitO 


Byte 


Session Number 


First 


Last 





Pacl<et Sequence Number 


1 


Bytes in Last Segment 


2 



Figure 7.12: Header last segment 



7.4.2 SLC ack mode header format 

Void 
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7.4.3 SLC header field definitions 



7.4.3.1 



Session number field 



The Session Number field contains the session number of the SAR session assigned by the Transmitting ST when a 
session is created. The ST initiating the packet shall set the session number. 



7.4.3.2 



First and last bits fields 



The First bit field specifies whether this packet is the first segment of a fragmented data packet. The Last bit field 
specifies whether this packet is the last segment of a fragmented data packet. 

For the following packet types, the First and Last bits are set as follows. 

Table 7.10: SLC-unacknowledged mode data packet types 



Data packet type 


First bit value 


Last bit value 


Unfragmented 


1 


1 


First segment of fragmented data 
packet 


1 





Any middle segment of fragmented 
data pacl<et 








Last segment of fragmented data 
packet 





1 



7.4.3.3 Packet sequence number field 

The Packet Sequence Number field is an 8-bit field, which specifies the sequence number of the SAR data packet. 

7.4.3.4 Cmp field 

The Cmp bit field specifies whether or not the SAR data is compressed. 
The Cmp bit field is set as follows: 

• Cmp bit field is set to " 1 " indicating this packet is compressed. 

• Cmp bit field is set to "0" indicating this packet is not compressed. 

7.4.3.5 Frm field 

The Frm bit field specifies whether or not there is a frame header present following the SLC header. 

The frame header is an application specific header, which might be used to provide additional information. 

The Frm bit field is set as follows: 

• Frm bit field is set to "1" indicating this packet has a frame header present. 

• Frm bit field is set to "0" indicating this packet has no frame header present. 

7.4.3.6 Sec field 

The Sec bit field specifies whether there is a Security header present in the first segment of a fragmented data packet. 
The Sec bit field is set as follows: 

• Sec bit field is set to "1" indicating this packet has a security header present. 

• Sec bit field is set to "0" indicating this packet has no security header present. 
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7.4.3.7 CRC type field 

The CRC Type field specifies whether or not there is a CRC field present appended to the end of the data field and its 
size. 

Table 7.11 : CRC type field encoding 



CRC type 


interpretation 





No CRC appended 


1 


16 bit CRC appended 


2 


32 bit CRC appended 


3 


64 bit CRC appended 



7.4.3.8 



Bytes in last segment field 



The Bytes in Last Segment field specifies the number of bytes in the Data field, padding bytes if any included by the 
security header of this packet, and all headers present and the CRC field. It should be interpreted as a positive integer 
format. 

7.4.3.9 E bit field 

The E bit, if set, indicates the presence of the SLC extension header. 
The E bit subfield is set as follows: 

• E bit subfield is set to "1" indicating this packet has an SLC extension header present. 

• E bit subfield is set to "0" indicating this packet has no SLC extension header present. 

7.4.4 SLC extension header format 

The SLC extension header format is shown in figure 7.13. 



(MSB) 
Bit? 


Bite 


Bits 


Bit 4 


Bit 3 


Bit 2 


Biti 


(LSB) 
BitO 


Byte 


Lengtii of Extension Header (conditional) =N 


4 


Type of Extension Header (conditional) 


5 


Value part of extension header (optional) 


6...N+3 



Figure 7.13: SLC extension header format 



7.4.4.1 



Extension header length field9 



This field indicates the length of the extension header, including the current octet in octets. It is to be interpreted as an 
integer in unsigned format. 

7.4.4.2 Extension header type 

The extension header type is an 8 bit value, which indicates the type of extension header. 

Table 7.12: Extension header type subfield values 



extension header type value 


extension header type 


0x01 


Destination MAC Address of 
sender 


all other values 


reserved 
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7.4.4.3 



Extension header value 



The extension header value is an optional variable length field. It shall be padded out to the length as indicated in the 
length field. The presence or absence of this field shall be deduced from the type. If the type is set to 0x01, the contents 
shall be taken as the Destination MAC Address of the sender, starting from the highest order bytes. The total length of 
the header value shall be four. 

An ST shall be able to read the E-bit subfield and if set to "1", read the extension header length subfield. An ST may not 
be able to read the extension header type or value, but shall be able to read any data field or CRC field present in the 
packet following the extension header value. 

7.4.5 Frame header format 

The frame header format is shown in figure 7.14. 



(MSB) 
Bit 7 


Bits 


Bits 


Bit 4 


Bits 


Bit 2 


Biti 


(LSB) 
BitO 


Byte 


Frame Header Value (8 bits) 






Figure 7.14: Frame header 

The frame header allows for conducting tests and for sending non-standard protocols in the future. 

If an ST receives a packet with frame header value set to a reserved value or a value not recognized by the ST, then the 
ST shall ignore the frame header. 

Table 7.13: Frame header value 



Frame hHeader Value 


Description 


00000110 


Diagnostic test controller satellite 
delay test (clause 5.8.4) 


00000111 


Diagnostic test controller SLC peer- 
to-peer delay test (clause 5.8.3) 


All other values 


Reserved 



7.4.6 Security header format 

The security header is shown in figure 7.15. 



(MSB) 
Bit 7 


Bits 


Bits 


Bit 4 


Bit 3 


Bit 2 


Biti 


(LSB) 
BitO 


Byte 


A/B 


Pad Count (2-0) 1 Initial Vector (27 - 24) 





Initial Vector (23 - 16) 


1 


Initial Vector (15 -8) 


2 


Initial Vector (7 - 0) 


3 



Figure 7.15: Security header 



7.4.6.1 A/B field 

Refer to the BSM RSM-A, TS 102 189-3 [7] for details. 



7.4.6.2 



Pad count field 



The pad count subfield identifies the number of padding bytes that were added to the user data to pad to 64-bit 
boundary. 
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7.4.6.3 



Initial vector field 



The initial vector subfield is a number generated at the source ST so that the encryption algorithm generates different 
bits even when the real data is identical, making it much more difficult for anyone to break the encryption mechanism. 
Refer to BSM RSM-A, TS 102 189-3 [7] for details. 

7.4.7 Null packet format 

The STs shall transmit null uplink RSM-A packets, shown in figure 7.16, to the satellite whenever necessary to fill a 
MAC block. The ST shall transmit null packets as required for synchronization probes, and uplink power control 
calibration probes. The ST shall always transmit a "0" for byte 0, bit 7. The network may transmit either a "0" or a " 1" 
for byte 0, bit 7. 



(MSB) 
Bit? 


Bite 


Bits 


Bit 4 


Bit 3 


Bit 2 


Biti 


(LSB) 
BitO 


Pacl<et 
Byte# 


Oor1 


1 


1 










1 











1 








1 




1 


1 


1 


1 








1 







1 


1 


2 











1 










1 


3 


1 


1 








1 










4 


1 


1 








1 







1 


5 











1 


1 





1 





6 


1 


1 


1 





1 


1 








7 


























8 








all" 


0"s 








9 








• • 


• 








• • • 


1 























107 



Figure 7.16: Null packet format prior to scrambling 



7.5 MAC/SLC message types 



Table 7.14 lists the MAC/SLC message types, and their direction, i.e, from ST to network or from network to ST. 
Transmission information packet, uplink power control status, bandwidth request, network information packet and 
indirect MIP messages are all MAC message types where the Destination MAC Address identifies the message type. 
See clause 7.3.2.1. The SLC Test message is an SLC message type where the Destination MAC Address identifies a 
multicast group or a specific terminal and the required frame header identifies the message type. See clause 7.4.5. 
Unrecognized messages shall be ignored upon receipt. 
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Table 7.14: MAC/SLC message types 



Message type 


Description 


Direction 


Reference Location 


Transmission 
Information Pacl<et 
(TIP) message 


Contains information on downlink power 
control, satellite ephemeris, and dedicated 
contention channels 


Nwk -> ST 


Clause 7.5.2 


Uplink Power Control 
Status message 


Contains information on uplink power control 
needed for the uplink power control algorithm 


Nwk -> ST 


Clause 7.5.3 


Bandwidth Request 
message 


Used by the ST to request uplink volume or 
rate bandwidth resources 


ST ->Nwk 


Clause 7.5.4 


Network Information 
Packet messages 
(NIP) 


Bandwidth assignment message 


Nwk -> ST 


Clause 7.5.5 


Negative acknowledgements message 


Nwk -> ST 


Clause 7.5.6 


Dynamic contention channel assignments 
message 


Nwk -> ST 


Clause 7.5.7 


Sent by one ST to another to inject test data 
over link 


ST -> ST 


Clause 7.5.9 


SLC Test message 


This set of messages contains fields that 
contain information needed by STs for 
accessing the network or accessing 
management functions. The open 
architecture of this message supports many 
information types in various orderings based 
on the current need for sending information to 
STs. Examples include the IP address of the 
NCC servers (including the Registration 
server), the ST addresses of the SSTs 
serving the NCC servers, and the interim 
addresses to be used by STs before they are 
registered. The MIP packets are classified as 
indirect MIP and direct MIP packet. The 
satellite multicasts indirect MIP at regular 
interval of time until stopped by NCC. The 
direct MIP is sent directly to the intended ST 
transparently through payload just like a 
normal RSM-A packet. 


Nwk -> ST 




Management 
Information Packet 
(MIP) messages 









7.5.1 



Common field definitions 



7.5.1.1 



Spare fields 



All spare fields shall be encoded as all zeros unless otherwise specified. Spare fields in received messages shall be 
ignored. 

7.5.1.2 Carrier mode field 

The carrier mode field indicates the uplink carrier mode as shown in table 7.15. 

Table 7.15: Carrier mode bit assignment 



Bit 7 


Bite 


Carrier mode 








128 Kbps 





1 


512 Kbps 


1 





2 Mbps 


1 


1 


1 6 Mbps 



All fields shall use binary coding unless otherwise stated. 
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7.5.1.3 



Rate 



The Rate field represents the least significant bit of the carrier mode where indicates 128 Kbps and 1 indicates 
512 Kbps. 



7.5.1.4 



D/C field 



The D/C field indicates the data/control mode for the contention channel where "00" represents "Control or Data", and 
"11" represents "Supervisory". The other two values are reserved. An ST shall not use contention channels, for which 
the D/C field value is "01" or "10". 

Contention channels with the data/control mode of "control or data" may have a rate of 128 kbps or 512 kbps. 
Contention channels with the data/control mode of "Supervisory" shall have a rate of 512 kbps. An ST shall ignore any 
contention channel assignment which has a rate which is not in accordance with these rules. 

7.5.1 .5 Sub band designator 

The sub band designator field is a 4-bit field. The values shall be as defined in BSM RSM-A TS 102 188-5 [3]. 

7.5.1.6 Carrier designator 

The carrier designator field is a 7-bit field. The values shall be as defined in BSM RSM-A TS 102 188-5 [3]. 



7.5.1.7 



Channel Group ID 



The channel group ID is a 15 bit number identifying the channel group. All STs belong to channel group ID 
"000000000000000" and shall be able to access all contention channel which as so designated. 

7.5.1 .8 Bandwidth Control ST ID 

The Bandwidth Control ST ID (BCSTID) is a 21-bit field. See clause 4.2.5. 



7.5.1.9 



A/B key 



If this field is set to use Key A, and if it is set to 1 the Key B is used. The ST obtains this information from the NCC 
when the BR session key is provided/updated. 

7.5.1 .10 Bandwidth control message common fields 

The bandwidth control messages have five common fields as shown in table 7.16. 

Table 7.16: Bandwidth control message common field format 



Bytebit 


bit? 1 bite 


bits 


bit 4 1 bits 1 bit 2 | Bit 1 | bit 


8 


message Type 
(2 bits) 


IFVer 


Number of assignments/ 
acl<nowledgements/spare (5 bits) 


9 


Uplink Frame number 8 bits) 


10 


number of contention channels/Spare 
(5 bits) 


Spare (3 bits) 
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7.5.1.10.1 



Message type 



This 2-bit field identifies one of the four different types of bandwidth control messages that ST may receive from the 
network. 

Table 7.17: Packet type 



Bits 7 6 


Value 


Description 


00 





Bandwidth assignment message 


01 


1 


Negative acknowledgement message 


1 


2 


Dynamic contention channel assignment message 


1 1 


3 


reserved 



7.5.1.10.2 IF version 

This field represents the interface version number. In the current version it is to be set to zero. 



7.5.1.10.3 



Number assignments/acknowledgements/spare (5 bits) 



If the message type is "assignment message" this field is the number of assignments which are included in the message. 
The maximum number of assignments is 9 and the minimum is 1. If the message type is "acknowledgement message" 
then this field is the number of acknowledgements which are included in the message. The minimum number of 
acknowledgements is 1 and the maximum number is 16. If the message type is "contention assignment message" than 
this field is spare. 

If ST receives a message with number of assignments/acknowledgements field set to an out-of -range value then ST 
shall drop this message. 



7.5.1.10.4 



Uplink frame number 



This field indicates the frame number for which the assignments contained in the packet are valid. The ST shall not use 
the time slots per the new assignment for transmission prior to the frame indicated by this field. The uplink frame 
number uses the TOD[12,5] format specified in BSM RSM-A TS 102 188-6 [4]. 



7.5.1.10.5 



Number of contention channels/spare 



If the message type is "Bandwidth assignment message" or "negative acknowledgement message" this field is spare. If 
the message type is "dynamic contention channel assignment message" then this field is the number of dynamic 
contention channels which are allocated by this message. This is a value between 1 and 20. 



7.5.1.11 



TOD check 



The TOD check field is the TOD frame count of the satellite master clock at the time the message is generated by the 
Satellite. The TOD check uses format TOD[36,5] as defined in BSM RSM-A TS 102 188-6 [4]. 



7.5.1.11.1 



Uplink frame number TOD check relationship 



The relationship between TOD check and uplink frame number in the same bandwidth assignment message is shown in 
figure 7.17. The uplink frame number is equal to Nh-5 for all assignment messages processed during BC frame N. 
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BC frame N 



ULframe N 



T N+1 
10-50 ms 



I 96 ms I 96 ms I 96 ms 

N+2 N+3 N+4 



N+5 



Figure 7.17: Relationship between uplinl< frame number and TOD checl< 

7.5.1.12 Padding byte 

Padding bytes shall be set to zero upon transmission and shall be ignored upon receipt. 

7.5.2 Transmission Information Packet message 

The transmission information packets are generated by the satellite and sent to STs within the entire coverage area. 

The transmission information packets are sent in multicast replication mode or when weather permitting in cellcast 
mode. 

The satellite static delay of the transmission information packet as defined with respect to the LHCP timing beacon 
epoch shall be less than or equal to 50 msec. This delay is computed assuming that the fast packet switch latency 
timeout is configured to 4 ms and excludes queuing delay. 

The satellite shall send transmission information packets to downlink microcells corresponding to each uplink cell at the 
rate of once per superframe. 

The transmission information packet format shall be as defined in figure 7.18. 



Byte# 


MSB 
bit 7 


bite 


bits 


bit 4 


bits 


Bit2 


biti 


LSB 
bitO 


8 


Spare 


FS1 


FS2 


Satellite Network ID | 


9 


Spare | CM | TM | CP | TP 


10 


Current PTP Slot number (1 Byte ) 


11 


Transition PTP Slot number (1 Byte ) 


12 


TDM Frame Transition superframe number 


13 


14 


15 


16 


TDM Frame Transition D/L frame number 


17 


Future Spare 1 


18 


19 


20 


21 


Future Spare 2 


22 


23 


24 


25 


26 


27 


28 


29 


30 


31 


32 


33 


34 
















1 
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Byte# 


MSB 
bit 7 


bite 


bits 


bit 4 


bits 


Bit2 


biti 


LSB 
bitO 


35 


TOD to UTC Offset ( 2 bytes) 


36 


37 


Absolute Superframe Count 


38 


39 


40 


41 


X Range ( 4 bytes) 


42 


43 


44 


45 


Y Range ( 4 bytes) 


46 


47 


48 


49 


Z Range ( 4 bytes) 


50 


51 


52 


53 


X Range Rate ( 4 bytes) 


54 


55 


56 


57 


Y Range Rate ( 4 bytes) 


58 


59 


60 


61 


Z Range Rate ( 4 bytes) 


62 


63 


64 


65 


Spare (4 bits) 


Nb cont (4-bits) 


66 


Spare 


Rate 


D/C (2-bit) 


Sub-band designator (4-bit) 


67 


Spare 


Carrier designator (7-bit) 


68 


Spare 


Channel Group ID (15-bit) 


69 




70 


Spare 


Rate 


D/C (2-bit) 1 Sub-band designator (4-bit) 1 


71 


Spare 


Carrier designator (7-bit) 


72 


Spare 


Channel Group ID (15-bit) 


73 




74 


Spare 


Rate 


D/C (2-bit) 1 Sub-band designator (4-bit) | 


75 


Spare 


Carrier designator (7-bit) 


76 


Spare 


Channel Group ID (15-bit) 


77 




78 


Spare 


Rate 


D/C (2-bit) 1 Sub-band designator (4-bit) 1 


79 


Spare 


Carrier designator (7-bit) 


80 


Spare 


Channel Group ID (15-bit) 


81 




82 


Spare 


Rate 


D/C (2-bit) 


Sub-band designator (4-bit) 


83 


Spare 


Carrier designator (7-bit) 


84 


Spare 


Channel Group ID (15-bit) 


85 




86 


Spare 


Rate 


D/C (2-bit) 


Sub-band designator (4-bit) 


87 


Spare 


Carrier designator (7-bit) 


88 


Spare 


Channel Group ID (15-bit) 


89 




90 


Spare 


Rate 


D/C (2-bit) 


Sub-band designator (4-bit) 


91 


Spare 


Carrier designator (7-bit) 


92 


Spare 


Channel Group ID (15-bit) 


93 




94 


Spare 


Rate 


D/C (2-bit) 


Sub-band designator (4-bit) 


95 


Spare 


Carrier designator (7-bit) 
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Byte# 


MSB 
bit? 


bite 


bits 


bit 4 


bits 


Bit2 


bit1 


LSB 
bitO 


96 


Spare 




Channel Group ID (16-bit) 






97 






98 


Spare 


• •• 
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Figure 7.18: Transmission Information Packet (TIP) message format 

7.5.2.1 Packet header field values 

The network shall use the following values for the packet header subfields, which are used for the TIP message. 

7.5.2.2 Transmission information packet message field definition 
7.5.2.2.1 Satellite Network ID 

The satellite network ID is a unique identifier of the RSM-A satellite network. The range of values are given by 
table 7.18. 

Table 7.18: satellite number subfield 



values 


Satellite Number 


00000 


Reserved 


00001 


1 


00010 


2 


00011 


3 



7.5.2.2.2 CM bit 

The CM bit indicates the current broadcast mode where represents 1/3 rate and 1 represents Va rate. 

7.5.2.2.3 TM bit 

The TM bit indicates the transition broadcast mode where represents 1/3 rate and 1 represents Va rate. 



7.5.2.2.4 



CPbit 



The CP bit indicates the Bandwidth control entity, to which the ST shall address bandwidth request messages, where 
represents CCl and 1 represents CC2. 



7.5.2.2.5 



IP bit 



The TP bit indicates the new transition control entity where represents CCl and 1 represents CC2. If TP = CP then no 
transition is planned. If TP does not equal CP, then a transition from the bandwidth control computer indicated by CP to 
the bandwidth control computer indicated by TP is planned. An ST shall enter CC transition mode whenever TP does 
not equal CP. 

A transition shall always take place in frame zero of a superframe and the CP and TP bits will be set equal in the TIP 
message in the same superframe. 



7.5.2.2.6 



Current PIP slot number 



The current (transition) PTP slot number field is an integer value indicating the current slot number of the first PTP 
burst in the current frame structure. Valid numbers configurable in the satellite range from 2 to 137. However, the 
network shall not set the current (transition) PTP slot number field to a value higher than 1 34 when the current 
(transition) broadcast mode is 1/4 rate. If the current (transition) PTP slot number field is ever set to a value greater than 
134, while the current (transition) broadcast mode is 1/4 rate, the ST shall assume the current (transition) PTP slot 
number is 2 until it receives a TIP with a value equal to or less than 134. See BSM RSM-A TS 102 188-6 [4] for exact 
value for every configuration. 
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7.5.2.2.7 Transition PTP slot number 



The transition PTP slot number field is an integer value indicating the transition slot number of the first PTP burst in the 
transition frame structure. Valid numbers range from 2 to 137. See BSM RSM-A TS 102 188-6 [4] for exact value for 
every configuration. 

7.5.2.2.8 TDM frame transition superframe number 

The TDM frame transition superframe number uses format TOD[39,8] (see BSM RSM-A TS 102 188-6 [4]) and is the 
absolute downlink superframe count at which the TDM frame format transitions to the configuration specified by the 
TM (transition broadcast modulation mode) and Transition PTP slot number fields. If the value of TDM frame 
transition superframe number is less than or equal to the value of the current absolute superframe count then no 
transition is planned. If the value of TDM frame transition superframe number is greater than the value of the current 
absolute superframe count then a transition is planned in the downlink superframe equal to this value. At all times the 
terminal shall use the current values specified by the CM field and the Current PTP slot number field. The Satellite shall 
update the TM and Transition PTP slot number fields when a transition is planned, and shall update the CM and Current 
PTP slot number fields when the transition takes place. 

7.5.2.2.9 TDM frame transition downlink frame number 

The TDM frame transition downlink frame number field indicates the downlink frame number (0 through to 255) within 
the specified superframe that the TDM frame format transition will occur. This field uses format TOD [7,0] (see BSM 
RSM-A TS 102 188-6 [4]).This field shall be encoded as "0000 0001". 



7.5.2.2.10 Future spare 1 and protocol switch 

7.5.2.2.10.1 FS1 bit spare 

The FS 1 bit in octet 8 is used as a protocol switch to indicate the satellite coding definition for the Future Spare 1 field. 
If FSl is zero, the satellite may encode arbitrary bits into bytes 17-20, and the ST shall ignore this field. If FSl is one, 
then the Future Spare 1 field shall have a definition to be specified in the future. An ST which supports only the basic 
capabilities set as defined in annex D, may ignore these bits. 

7.5.2.2.10.2 Future spare 1 
See FSl bit. 

7.5.2.2.1 1 Future spare 2 and protocol switch 

7.5.2.2.11.1 FS2bit 

The FS2 bit in octet 8 is used as a protocol switch to indicate the satellite coding definition for theFuture Spare 2 fields. 
If FSl is zero, the satellite may encode arbitrary bits into bytes 21-34, and the ST shall ignore the Future Spare 2 field. 
If FSl is one, then the Future Spare field shall have a definition to be specified in the future. An ST which supports only 
the basic capabilities set as defined in annex D, may ignore these bits. 

7.5.2.2.11.2 Future spare 2 
See FS2 bit. 

7.5.2.2.1 2 TOD to UTC offset 

The TOD-to-UTC offset is a 16 bit number representing the offset between the satellite TOD count relative to UTC. 
LSB resolution is 768 msec (RSM-A superframe). MSB is a sign bit where "1" is "plus" and "0" is "minus". Refer to 
BSM RSM-A TS 102 188-6 [4] for usage. 

7.5.2.2.13 Absolute superframe count 

The Absolute superframe count is a 32 bit number representing the payload TOD with a resolution of 768 msec using 
the format TOD[39,8]. See BSM RSM-A TS 102 188-6 [4]. 
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7.5.2.2.14 Ephemeris data 



This ephemeris information in the transmission information packet shall be computed relative to UTC (not TOD). 
(See BSM RSM-A TS 102 188-6 [4]). 

Ephemeris Data fields are used to indicate the range and range rate. The 32 bit range numbers (bytes 41 through 52) are 
fixed point representation of the range such that the LSB is 0.1 meter. The 32 bit range rate numbers (bytes 53 through 
64) are fixed point representation of the range rate such that the LSB is 1 micrometer/sec. The coordinate reference 
frameis WGS84[8]. 

7.5.2.2.15 Nbcont 

The NB cont field uses Byte 65, bits 3 through 0. The Nb cont field is the number of static contention channels which 
are allocated by this message. The value "0000" indicates that there are no contention channels allocated. There cannot 
be more than 8 contention channels allocated by this message. 

7.5.2.2.16 Dedicated contention channel information 

Bytes 66 through 97 are used to provide information on Nb cont contention channels. Each subfield which is used to 
define each channel is described in clause 7.5.1. 

7.5.3 ULPC status message format 

The Uplink Power Control function is used to control ST transmit power to attain the following objectives: 

• Assure adequate margins against interference and atmospheric effects to meet the uplink packet loss rate and 
power control error objectives. 

• Compensate for the ST RE imperfections such as power versus frequency variation. 

The ULPC process is distributed between the satellite and STs. The STs adjust their transmit uplink power per carrier 
frequency based on beacon power measurements and satellite power measurement feedback of uplinked packets. Thus, 
the satellite is responsible for maintaining a stable beacon signal over time, and performing power and early/late 
measurements on uplinked packets. 

In order to assist STs with adjusting transmitted uplink signal power and uplink signal timing, the satellite shall measure 
the received quality of uplink frames and feed back the following set of metrics via uplink power control status packets: 

• Noise measurement of the noise estimation period in each uplink frame. 

• Signal-to-noise measurement of each time slot in each uplink. 

• Block decoder error values of the first code block of each time slot in each uplink frame. 

• Early/late timing indication of the burst of each time slot in the uplink frame. 
The satellite shall transmit the uplink power control status packets in cellcast mode. 

The uplink power control status packets shall be formatted as defined in figure 7.19 through figure 7.22. 
There is one packet format per carrier mode. 
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(MSB) 














(LSB) 




bit? 


bite 


bits 


bit 4 


bit 3 


bit 2 


biti 


bitO 


Bvte# 


Carrier Mode 


sub band desianator (4 bits) 


carrier desianator 


8 


Carrier desianator (7 bits) 1 (IVISB) UDlinl< Frame Number (LSB) 


9 


(MSB) 


Suoerframe Number 


(LSB) 


10 


(MSB) 


Noise Measurement of 1st 2 Mbos bandwidth comoosina this 16 Mbos 


(LSB) 


11 


(MSB) 


Noise Measurement of 2nd 2 Mbos bandwidth comoosina this 16 Mbos 


(LSB) 


12 


(MSB) 


Noise Measurement of 3rd 2 Mbos bandwidth comoosino this 16 Mbos 


(LSB) 


13 


(MSB) 


Noise Measurement of 4th 2 Mbos bandwidth comoosina this 16 Mbos 


(LSB) 


14 


(MSB) 


Noise Measurement of 5th 2 Mbos bandwidth comoosina this 16 Mbos 


(LSB) 


15 


(MSB) 


Noise Measurement of 6th 2 Mbos bandwidth comoosina this 16 Mbos 


(LSB) 


16 


(MSB) 


Noise Measurement of 7th 2 Mbos bandwidth comoosina this 16 Mbos 


(LSB) 


17 


(MSB) 


Noise Measurement of 8th 2 Mbos bandwidth comoosina this 16 Mbos 


(LSB) 


18 


(MSB) 


SNR - TS 






1 (LSB) 


(MSB) 


19 


Decoder Metric -TS 


(LSB) 


E/L TS 


(MSB) 


SNR - TS 1 




20 






(LSB) 


(MSB) 


Decoder Metric - TS 1 


(LSB) 


E/L TS 1 


21 


(MSB) 


SNR - TS 02 








(LSB) 


(MSB) 


22 


Decoder Metric -TS 2 


(LSB) 


E/L TS 2 


(MSB) 


SNR - TS 3 




23 






(LSB) 


(MSB) 


Decoder Metric - TS 3 


(LSB) 


E/L TS 3 


24 
























































(MSB) 


SNR - TS 30 








(LSB) 


(MSB) 


64 


Decoder Metric -TS 30 


(LSB) 


E/L TS 30 


(MSB) 


SNR-TS31 




65 




(LSB) 


(MSB) 


Decoder Metric - TS 31 1 (LSB) 


E/L TS 31 


66 


All Zero Pattern 


67 
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Figure 7.19: 16 lUlbps carrier mode ULPC status message format 


(MSB) 














(LSB) 




bit 7 


bite 


bits 


bit 4 


bit 3 


bit 2 


biti 


bitO 


Bvte# 


Carrier Mode 


Sub band desianator 


carrier desianator 


8 


Carrier desianator (7 bits) 1 (MSB) Uolink Frame Number (LSB) 


9 


(MSB) 


Suoerframe Number 


(LSB) 


10 


(MSB) 


Noise Measurement of this 2 Mbos carrier 


(LSB) 


11 


























12 


























13 


























14 


























15 


























16 


























17 


























18 


(MSB) 


SNR - TS 








(LSB) 


(MSB) 


19 


Decoder Metric -TS 


(LSB) 


E/L TS 


(MSB) 


SNR - TS 1 




20 






(LSB) 


(MSB) 


Decoder Metric - TS 1 


(LSB) 


E/L TS 1 


21 


(MSB) 


SNR - TS 02 








(LSB) 


(MSB) 


22 


Decoder Metric -TS 2 


(LSB) 


E/L TS 2 


(MSB) 


SNR - TS 3 




23 






(LSB) 


(MSB) 


Decoder Metric - TS 3 


(LSB) 


E/L TS 3 


24 
























































(MSB) 


SNR - TS 30 








(LSB) 


(MSB) 


64 


Decoder Metric -TS 30 


(LSB) 


E/L TS 30 


(MSB) 


SNR-TS31 




65 




(LSB) 


(MSB) 


Decoder Metric - TS 31 1 (LSB) 


E/L TS 31 


66 


All Zero Pattern 


67 
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Figure 7.20: 2 Mbps carrier mode ULPC status message format 
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(MSB) 














(LSBI 






bit 7 


bite 


bits 


bit 4 


bits 


bit 2 


biti 


bitO 


Bvte# 




Carrier Mode 


Sub band desianator 


carrier desianator 


8 




Carrier desianator (7 bits) 1 (IVISB) UDlinl< Frame Number (LSB) 


9 




(MSB) 


Suoerframe Number 


(LSB) 


10 




(MSB) 


Noise Measurement over 2 Mbos bandwidth that contains this 51 2 kbos 


(LSB) 


11 




(MSB) 


SNR - TS 






1 (LSB) 


(MSB) 


12 


Carrier k 


Decoder Metric -TS 


(LSB) 


E/L TS 


(MSB) 


SNR - TS 1 




13 








(LSB) 


(MSB) 


Decoder Metric - TS 1 


(LSB) 


E/L TS 1 


14 




(MSB) 


SNR - TS 02 








(LSB) 


(MSB) 


15 




Decoder Metric -TS 2 


(LSB) 


E/L TS 2 


(MSB) 


SNR - TS 3 




16 








(LSB) 


(MSB) 


Decoder Metric - TS 3 


(LSB) 


E/L TS 3 


17 
























(MSB) 


SNR - TS 30 








(LSB) 


(MSB) 


57 




Decoder Metric -TS 30 


(LSB) 


E/L TS 30 


(MSB) 


SNR-TS31 




58 








(LSB) 


(MSB) 


Decoder Metric - TS 31 


(LSB) 


E/L TS 31 


59 




(MSB) 


SNR - TS 








(LSB) 


(MSB) 


60 


Carrier k+1 


Decoder Metric -TS 


(LSB) 


E/L TS 


(MSB) 


SNR - TS 1 




61 








(LSB) 


(MSB) 


Decoder Metric - TS 1 


(LSB) 


E/L TS 1 


62 




(MSB) 


SNR - TS 02 








(LSB) 


(MSB) 


63 




Decoder Metric -TS 2 


(LSB) 


E/L TS 2 


(MSB) 


SNR - TS 3 




64 








(LSB) 


(MSB) 


Decoder Metric - TS 3 


(LSB) 


E/L TS 3 


65 
























(MSB) 


SNR - TS 30 








(LSB) 


(MSB) 


105 




Decoder Metric -TS 30 


(LSB) 


E/L TS 30 


(MSB) 


SNR-TS31 




106 






(LSB) 


(MSB) 


Decoder Metric - TS 31 1 (LSB) 


E/L TS 31 
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Figure 7.21 : 512 Kbps carrier mode ULPC status message format 


(MSB) 














(LSB) 






bit 7 


bite 


bits 


bit 4 


bits 


bit 2 


biti 


bitO 


Bvte# 




Carrier Mode 


Sub band desianator 


carrier desianator 


8 




Carrier desianator 1 (MSB) UDlinl< Frame Number (LSB) 


9 




(MSB) 


Suoerframe Number 


(LSB) 


10 




(MSB) 


Noise Measurement over 2 Mbos bandwidth that contains this 128 kbos 


(LSB) 


11 




(MSB) 


SNR - TS 






1 (LSB) 


(MSB) 


12 


Carrier k 


Decoder Metric -TS 


(LSB) 


E/L TS 


(MSB) 


SNR - TS 1 




13 








(LSB) 


(MSB) 


Decoder Metric - TS 1 


(LSB) 


E/L TS 1 


14 




(MSB) 


SNR - TS 02 








(LSB) 


(MSB) 


15 




Decoder Metric -TS 2 


(LSB) 


E/L TS 2 


(MSB) 


SNR - TS 3 




16 








(LSB) 


(MSB) 


Decoder Metric - TS 3 


(LSB) 


E/L TS 3 


17 
























(MSB) 


SNR - TS 6 








(LSB) 


(MSB) 


21 




Decoder Metric -TS 6 


(LSB) 


E/L TS 6 


(MSB) 


SNR - TS 7 




22 






(LSB) 


(MSB) 


Decoder Metric - TS 7 1 (LSB) 


E/L TS 7 


23 




All Zero Pattern (shown below) 


24 








































59 




(MSB) 


SNR - TS 








(LSB) 


(MSB) 


60 


Carrier k+1 


Decoder Metric -TS 


(LSB) 


E/L TS 


(MSB) 


SNR - TS 1 




61 








(LSB) 


(MSB) 


Decoder Metric - TS 1 


(LSB) 


E/L TS 1 


62 




(MSB) 


SNR - TS 02 








(LSB) 


(MSB) 


63 




Decoder Metric -TS 2 


(LSB) 


E/L TS 2 


(MSB) 


SNR - TS 3 




64 








(LSB) 


(MSB) 


Decoder Metric - TS 3 


(LSB) 


E/L TS 3 


65 
























(MSB) 


SNR - TS 6 








(LSB) 


(MSB) 


69 




Decoder Metric -TS 6 


(LSB) 


E/L TS 6 


(MSB) 


SNR - TS 7 




70 






(LSB) 


(MSB) 


Decoder Metric - TS 7 1 (LSB) 


E/L TS 7 


71 




All Zero Pattern 


72 
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7.5.3.1 



Figure 7.22: 128 Kbps carrier mode ULPC status message format 



ULPC status message field definition 



The ULPC status message header contains three bytes (Bytes 8 to 10) of information that is applicable to all of the 
uplink carrier modes. 
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7.5.3.1.1 



Carrier groupings 



If the carrier mode is either the 128 Kbps or 512 Kbps, the carrier pairing is used as described in table 7.19. In this case, 
the reported carrier designator is the smaller of the two that are paired. 

Table 7.19: Carrier grouping 



Adjacent Uplink Carriers Pairs for 
512 l<bps (Standard Slot) or 128 kbps (Long Slot) Mode 


0,1 


2,3 


4,5 




• • • 


90,91 


92,93 


94,95 



NOTE: The carrier sub-field contained in bytes 8 and 9 represent the lower-numbered carrier of the pair of 
adjacent carriers. There is no pairing for the 2 Mbps and 16 Mbps standard slot modes. 



7.5.3.1.2 



Uplink frame number field 



The uplink frame number field is the relative uplink frame number using format TOD[7,5] (BSM RSM-A 

TS 102 188-6 [4] for which uplink power control status is being reported. The uplink frame number is the same for all 

time slot measurements reported by this message. 



7.5.3.1.3 



Superframe number field 



The superframe number field is the 8 Isbs of the absolute superframe count using format TOD[15,8] (see BSM RSM-A 
TS 102 188-6 [4]) for which uplink power control status is being reported. The superframe number is the same for all 
time slot measurements reported by this message. 



7.5.3.1.4 



Noise measurement field 



The uplink noise measurement subfield correlates with carrier bandwidth as defined in BSM RSM-A TS 102 188-6 [4]. 
This 8-bit value can be used to obtain an estimate of the noise density at the satellite. The uplink noise measurement 
subfield is an integer with a value between and 255. It's use is described in BSM RSM-A TS 102 188-6 [4]. 

7.5.3.1 .5 Time slot measurement field 

The uplink power control status packet message contains one set of measurements per time slot per carrier. 

The satellite measures the signal to noise ratio reported in the SNR subfield, block decoder errors reported in the block 
decoder subfield, and early/late timing arrival indication of the uplink burst in the E/L subfield. There are 12 bits for 
each measurement set as defined in table 7.20. 

Table 7.20: Number of bits per time slot measurement 



SNR 


Block Decoder 


E/L 


7 bits 


4 bits 


1 bit 



The SNR subfield is an integer value between and 127. 
The block decoder subfield is defined in table 7.21. 
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Table 7.21 : Block decoder 



Block decoder subfield 


RS indication 


1111 


RS failure 


All other values 


RS pass 



More detailed definition of the SNR and block decoder subfield are given in BSM RSM-A TS 102 188-5 [3]. 

Only the "1111" value is to be interpreted as a RS fail indication. All other values are to be interpreted as a RS pass 
indication. 

A value for E/L subfield of "0" indicates that the corresponding uplink burst arrived early within the uplink time slot 
and a value of "1" indicates that the corresponding uplink burst arrived late within the uplink time slot. 

The use of these parameters is further described in BSM RSM-A TS 102 188-5 [3]. 

7.5.4 Bandwidth request message 

The ST MAC layer shall use the bandwidth request packet for rate or volume requests. The ST may combine rate and 
volume request messages within a single packet. However, each request within a bandwidth request packet shall be 
treated independently. The ST sets the appropriate fields and formats them. The packet format for a bandwidth request 
is given in table 7.22. 

Table 7.22: Bandwidth Request Packet 



Byte/bit 


bit 7 bite Bits bit 4 bits bit 2 bit 1 bitO 


8 

12 


Authorization information 


13 
15 


Spare 


16 
19 


Frame count 


20 
25 


Bandwidth Request Header 


26 


Bandwidth Request Data # 1 


32 


Bandwidth Request Data # 2 


38 


Bandwidth Request Data # 3 


44 


Bandwidth Request Data # 4 


50 


Bandwidth Request Data # 5 


56 
63 


Spare 


64 
67 


Integrity Checl< (4 bytes) 


68 
95 


Spare 


96 

107 


Padding bytes 



7.5.4.1 



Authorisation information 



This 5-byte field is reserved for a future application. The ST shall encode this field with all zeros and the network shall 
ignore it. 



7.5.4.2 



Frame Count 



The ST shall encode the frame count with the uplink frame count at the time the message is generated, just prior to 
sending it to the SAM for validation as described in BSM RSM-A SMAC/SLC interface specification TS 102 189-3 [7]. 
This uses format TOD[36,5] as described in BSM RSM-A TS 102 188-6 [4]. 
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7.5.4.3 Bandwidth Request Header 

This 6-byte field is detailed in the table 7.23. 

Table 7.23: Bandwidth Request Header 



Byte/Bit 


Bit 7 
(IVISB) 


bite 


bits 


bit 4 


bits 


bit 2 


biti 


bitO 
(LSB) 





Spare (3 bits) 




BCSTID (21 bits) 




1 






2 




3 


Uplink cell ID (8 bits) | 


4 


Spare 


Num Requests (3 
bits) 


Spare 


A/B 
key 


IFV 


BC 


5 


AA 


carrier mode 


Spare (5 bits) 



7.5.4.3.1 Uplink Cell ID 

This 8-bit field contains the uplink cell ID. 



7.5.4.3.2 



Number of Requests 



This 3-bit field represents the number of bandwidth requests that are contained within one message. If the BCS receives 
one of the reserved values in number of requests field then it shall drop the bandwidth request packet. 

Table 7.24: Number of requests 



Bits 6 5 4 


Value 


Description 








Reserved 


1 


1 


One BW request in the packet 


1 


2 


Two requests in the packet 


1 1 


3 


Three requests in the packet 


1 


4 


Four requests in the packet 


1 1 


5 


Five requests in the packet 


1 1 


6 


Reserved 


1 1 1 


7 


Reserved 



7.5.4.3.3 



Void 



7.5.4.3.4 



IFV 



This field specifies the interface version that supports up to two versions of the request format. For the current version, 
the IF V field shall be set to zero. If the BCS receives bandwidth request packet with IF V field set to " 1 " then it shall 
drop the bandwidth request packet. 

Table 7.25: IF version 



Biti 


Description 




1 


Version of the request format 
Reserved for future use 
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7.5.4.3.5 BC 

Depending on the uplink cell to which the ST belongs, it sets the BC bit. This is provided to the ST in the TIP. 

Table 7.26: BC bit 



BitO 


Description 





Bandwidth Control 1 


1 


Bandwidtli Control 2 



7.5.4.3.6 



AAbit 



The AA (aloha or assignment ) bit identifies whether the bandwidth request message is sent by the ST via a contention 
(aloha) channel or on an assigned (for rate or volume) time slot. 

Table 7.27: AA bit definition 



Bit 7 


Description 





Request is sent via the contention channel 


1 


Request is sent using an assigned time slot 



7.5.4.4 



Bandwidth request data 



Five bandwidth request data messages can be packed in a single request packet. Each of the bandwidth request message 
is 6 bytes in length. The request data format is shown in table 7.28. 

Table 7.28: Bandwidth request data 



Byte 


Bit? 


bite Bits bit 4 bit 3 


bit 2 bit 1 


bitO 





Follow- 
up bit 


Sub band Designator/Spare 
(4 bit) 




1 


Destination Region ID (1 1-bit) | 


2 


Spare (3-bit) Request action 




3 


Number Slots (11 -bit) | 


4 


Carrier Designator/Spare (7-bit) 




5 


Request ID (9-bit) 



7.5.4.4.1 



Follow-up bit 



The ST shall set this bit to 1 to identify explicitly to the network that this is a follow-up request going to the same 
destination. For a new or original request, this bit is set to 0. 



7.5.4.4.2 



Sub band designator/Spare 



The ST shall set this field to the sub band designator for the sub band in which the ST is requesting resource if the 
request action is "Test request", otherwise the ST shall set this field as spare. 



7.5.4.4.3 



Destination region ID 



This 1 1-bit field identifies the destination region. The ST shall set this field for volume requests only. For the rate 
request, this field is set to all ones by the ST and ignored by the network. The ST shall set this field to indicate shaped 
beam if it is sending Volume shaped beam traffic. The ST shall set this to wildcard if it is configured to aggregate all 
traffic to a clustered set of downlink cells into a single BC request. 



7.5.4.4.4 



Request action 



The request action specifies the type of request that the ST may originate. The field indicates if the request being 
originated is a new rate request or a volume request, a modification of the existing rate request, a de-allocation of an 
existing request, or if it is the initiation of a test request. 
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Table 7.29: Request action 



Bit 4 


Bits 


Value 


Description 











Rate request/volume request - Initiate a new request (rate or 
volume - see note). 





1 


1 


Rate modification - Change the existing rate request (only for rate) 


1 





2 


Rate de-allocation - Cancel or de-allocate the existing rate request 
(only for rate) 


1 


1 


3 


Test request (only for volume) 



NOTE: Rate requests and Volume requests can be distinguished by the Request ID field as defined in 
clause 7.5.4.4.7. 



7.5.4.4.5 



Number of slots 



The 11 -bit field represents the number of slots a ST may request in a given request. The Satellite will add 1 to the value 
specified in this field for rate and volume requests. For rate requests, this number specifies the number of slots required 
in every frame. The ST will enter a number in the valid range of to 3 1 for rate requests. For volume requests, this field 
specifies the total number of slots required to service a particular burst of traffic. The valid range is 0-2 047. However, 
it may be limited to a maximum value that is configurable by the NCC. 



7.5.4.4.6 



Carrier designator/spare 



The ST shall set these seven bits to the carrier designator (see BSM RSM-A TS 102 188-5 [3]) of the uplink channel in 
which the ST is requesting bandwidth if the request action is "test request". Otherwise this field is spare. 



7.5.4.4.7 



Request ID 



This 9-bit request ID field is associated with each individual request. If this field is set to 0, it indicates low priority rate 
request. If this is set to 1, it indicates high priority request. Low priority volume request will have values in pairs such as 
2-3, 4-5, 6-7, up to 256-257. High priority volume requests can have values in pairs from 258-259, 
260-26 1 , ... ,5 1 0-5 1 1 . For volume requests of a given destination and priority, a unique request ID pair is assigned by the 
ST. If the original request is assigned 2, the subsequent follow-up request can be assigned the request ID of 3, the 
following request for the same destination and priority is assigned 2 again. Thus the values in each of the pair is toggled 
to represent the successive requests for the given priority and destination. Note that if the request action indicates a test 
request the request ID can only be for volume; request ID and 1 are not valid codings if the request action indicates 
test request. 

Table 7.30: Request ID 



Request ID 


Description 





Low Priority Rate 


1 


High Priority Rate 


2-3 


Low Priority Volume for Destination A 


4-5 


Low Priority Volume for Destination B 






256-257 


Low Priority Volume for Destination Z 


258-259 


High Priority Volume for Destination 1 


260-261 


High Priority Volume for Destination 2 






510-511 


High Priority Volume for Destination #N 



7.5.4.5 



Integrity check 



This 4-byte field contains the Message Integrity Check code that SAM assigns to each Bandwidth Request message that 
the ST originates. See BSM RSM-A, SMAC/SLC interface specification TS 102 189-3 [7]. 
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7.5.5 



Bandwidth assignment message 

Table 7.31 : Bandwidth assignment message format 



Byte/bit 


bit? bite bits bit 4 bit 3 bit 2 Bit 1 


bitO 1 


8 


Bandwidth Control message common fields 
(see clause 7.5.1) 


9 


10 


11 

19 


Assignment field* 1 


20 
28 


Assignment field # 2/padding 


29 
37 


Assignment field # 3/padding 


38 
46 


Assignment field #4/padding 


47 
55 


Assignment field #5/padding 


56 
64 


Assignment field #6/padding 


65 
73 


Assignment field #7/padding 


74 
82 


Assignment field # 8/pading 


83 

91 


Assignment field #9/padding 


92 
103 


Padding bytes 


104 
107 


TOD check 
(see clause 7.5.1) 



7.5.5.1 



Assignment field 



The assignment field that actually contains the channel numbers, slot numbers and total number of slots assigned to the 
particular ST is detailed in table 7.32. In case there is no assignment field, this field shall be padded out with zeros. 

The assignment field of the assignment packet is a 9-byte field and details the exact assignment such as the slot 
numbers, and the channel number that the given ST is authorised to transmit. 

Table 7.32: Assignment field format 



Byte/Bit 


bit 7 bit 6 Bit 5 


Bit 4 bit 3 bit 2 Bit 1 bitO 





Spare (3-bit) 




1 




BCSTID(21-bit) 


2 




3 


A/B 
key 


TSMF 


spare 


Start index (5-bit) 


4 


Number of consecutive indices (5-bit) | Last | Carrier mode 


5 


Number of frames 
(3-bit) 


Spare 


Sub-band designator (4-bit) 


6 


carrier designator (7-bit) | Req ID 


7 


Request ID ( 9-bit) 


8 


Assignment Integrity Check (8-bit) 



7.5.5.1.1 



TSMF 



The TSMF bit identifies the time slot mapping function which the ST shall use to determine the actual time slots, which 
are assigned to it, from the start position and number of consecutive positions fields. If this bit is "0", the ST shall use 
the time slot mapping function defined in annex A. The value "1" is reserved. 
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7.5.5.1.2 Start index 



This field indicates the starting index, that is assigned to the given ST. Range of values is 0-3 1 . Start index is defined in 
annex A. 

7.5.5.1 .3 Number of consecutive indices 

This 5-bit field represents the number of consecutive indices beginning from the start index number that the ST is 
assigned for future transmission in the indicated frame or frames. The ST shall derive the actual time slot assignment 
using the start index and number of consecutive indices values using the time slot mapping function given in 
annex A. 

7.5.5.1.4 Last 

This bit indicates that the given assignment is the last assignment for the requested volume bandwidth. All of the 
allocations have already been made, and ST shall remove this request as it has already been serviced. If ST has more 
data to send, it can use one of the allocated slots to make a new request. 

7.5.5.1.5 Number of frames 

This field specifies the duration for which the assignment is valid. Occasionally, the ST may not receive allocations 
every frame. During these periods, the ST shall continue to use the channel and the slots that were assigned for the 
specified number of frames, as an exception. Normally, the ST shall receive the allocations every frame. For rate 
assignments, this field would be set for n=0, 1,2,3,4,5,6,7 to indicate values of 2n=l, 2, 4, 8, 16, 32, 64 or 128 frames 
respectively. 

7.5.5.1.6 Request ID 

This identifies the request for which the assignment is being sent. Refer to the request ID field in the BW request header 
format. See clause 7.5.4.4.7. The Source ID and Request Id pair are unique in a given bandwidth assignment packet. 

7.5.5.1 .7 Assignment integrity check 

The 8-bit field is given by the BCS. The ST shall pass the packet to the SAM. The SAM then verifies authenticity of the 
assignment messages received from the satellite for this ST. This is done for all assignment messages received, for both 
rate and volume. Refer to the BSM RSM-A, TS 102 189-3 [7]. 

7.5.6 Negative acknowledgement message 

The format for the negative acknowledgement message is defined in table 7.33. 
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Table 7.33: Negative Acknowledgement message definition 



Byte/bit 


bit? bite bits bit 4 bits bit 2 Bit 1 


bitO 1 


8 


Bandwidth Control message common fields 
(see clause 7.5.1) 


9 


10 


11 
15 


Acknowledgement field* 1 


16 
20 


Acknowledgement field # 2/pad 


21 
25 


Acknowledgement field # 3/pad 


26 

30 


Acknowledgement field #4/pad 


31 
35 


Acknowledgement field #5/pad 


36 

40 


Acknowledgement field #6/pad 


41 
45 


Acknowledgement field #7/pad 


46 
50 


Acknowledgement field # 8/pad 


51 
55 


Acknowledgement field # 9/pad 


56 
60 


Acknowledgement field # 1 0/pad 


61 
65 


Acknowledgement field # 1 1/pad 


66 

70 


Acknowledgement field # 1 2/pad 


71 
75 


Acknowledgement field # 1 3/pad 


76 
80 


Acknowledgement field # 14/pad 


81 
85 


Acknowledgement field # 1 5/pad 


86 

90 


Acknowledgement field # 1 6/pad 


91 
103 


Padding bytes 


104 
107 


TOD check 
(see clause 7.5.1) 



7.5.6.1 



Acknowledgement fields 1-16 



The detail format of the acknowledgement is shown in table 7.34. If there is no valid acknowledgement message, this 
field is set to all zeros. 

Table 7.34: Acknowledgement field format 



Byte/bit 


Bit 7 Bit 6 bit 5 


bit 4 Bits bit 2 bit 1 


bitO 





spare (3-bit) 






1 




3CSTID (21 bits) 


2 




3 


Cause Code (4 bits) Spare (3-bit) 




4 


Request ID (9 bits) 
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7.5.6.1.1 Cause code 

The cause code is defined in table 7.35. 



Table 7.35: Cause code definition 



Cause code 


NACK reason 


Possible explanation 


ST action 


RATE REQUEST 


0001 


No bandwidth 


Network reconfiguration 


ST shall increment 






Fragmented channels. 


RETRY_COUNT If the count 
is less than 

MAX_NO_RETRY, ST shall 
reissue the request. 
Otherwise ST shall declare 
failure to CM entity. 


1010 


Rate request of 


Previous rate request of same priority 


ST shall execute rate-change 




specified priority 


that ST believes was deleted is still 


procedure. 




already exists 


active at BCS. 




1011 


Invalid number of 


Configuration error. 


ST shall increment 




slots specified in 




RETRY COUNT. If the count 




request message 




is less than 

MAX_NO_RETRY, ST shall 
reissue the request. 
Otherwise ST shall declare 
failure to CM entity. 


1100 


Total number of 


Previous rate request of same priority 


ST shall increment 




rate slots to this ST 


that ST believes was deleted is still 


RETRY COUNT. If the count 




exceeds maximum 


active at BCS. 


is less than 




for specified 




MAX NO RETRY, ST shall 




channel rate 




reissue the request. 
Otherwise ST shall declare 
failure to CM entity. 


1101 


Bad packet header 


Configuration error. 


ST shall increment 




- UL beam, number 




RETRY COUNT. If the count 




of requests, 




is less than 




interface version 




MAX_NO_RETRY, ST shall 
reissue the request. 
Otherwise ST shall declare 
failure to CM entity. 


All other 




Unexpected cause code for this 


ST shall ignore NACK. 


values 




request type. 




RATE MODIFICATION REQUEST 


1110 


No existing request 


ST's rate was deleted and a rate 


ST shall declare failure to CM 




found of specified 


change was sent before the ST 


entity. 




priority from this ST 


detected its allocations ceased. Rate 
was deleted for one of the following 
reasons: 

1) NCC deleted ST's rate because 
keep-alives were not received. 

2) ST's rate removed because of 
LPR pre-emption. 

3) ST's rate removed because old 
channel did not have enough slots 
and no new channels were 
available. 




1011 


Invalid number of 


Configuration error. 


ST shall increment 




slots specified in 




RETRY COUNT. If the count 




request message 




is less than 

MAX_NO_RETRY, ST shall 
reissue the request. 
Otherwise ST shall declare 
failure to CM entity. 
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Cause code 


NACK reason 


Possible explanation 


ST action 


1100 


Total number of 
rate slots to this ST 
exceeds maximum 
for specified 
channel rate 


Previous rate request of same priority 
that ST believes was deleted is still 
active at BCS. 


ST shall increment 
RETRY_COUNT. If the count 
is less than 

MAX_NO_RETRY, ST shall 
reissue the request. 
Otherwise ST shall declare 
failure to CM entity. 


1101 


Bad packet header 
- UL beam, number 
of requests, 
interface version 


Configuration error. 


ST shall increment 
RETRY_COUNT. If the count 
is less than 

MAX_NO_RETRY, ST shall 
reissue the request. 
Otherwise ST shall declare 
failure to CM entity. 


All other 
values 


- 


Unexpected cause code for this 
request type. 


ST shall ignore NACK. 


RATE DE-ALLOCATION 


1110 


No existing request 
found of specified 
priority from this ST 


ST's rate was deleted and a rate 
deallocation request was sent before 
the ST detected its allocations 
ceased. 

1) NCC deletes ST's rate because 
keep-alive messages were not 
received. 

2) ST's rate removed because of 
LPR pre-emption. 

3) ST's rate removed because old 
channel did not have enough slots 
and no new channels were 
available. 


ST shall declare success to 
CM entity. 


All other 
values 


- 


Unexpected cause code for this 
request type. 


ST shall ignore NACK. 


VOLUME REQUEST | 


0001 


No bandwidth 
(admit thresholds 
exceeded for 
specified UL beam 
and channel rate) 


Temporary congestion at BCS 
caused by too many unallocated 
volume slots for given UL and 
channel rate. 


The ST shall restart the 
allocation timer at its current 
value. ST shall evaluate the 
queue on expiry of the 
allocation timer and issue a 
new volume Request. 


All other 
values 


- 


Unexpected cause code for this 
request type. 


ST shall ignore NACK. 



7.5.6.1.2 Request ID 

This identifies the request for which the assignment is being sent. Refer to the request ID field in clause 7.5.4.4.7. 

7.5.7 Dynamic contention cinannel assignment message 

The dynamic contention channel assignment message is shown in table 7.36. This message contains the details about 
the various contention channels that can be used by the ST to transmit bandwidth requests or other control or user data. 
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Table 7.36: Dynamic contention chiannel assignment message definition 



Byte/bit 


bit? bite bits bit 4 bits bit 2 Bit 1 bit 


8 


Bandwidth Control message common fields 
(see clause 7.5.1) 


9 


10 


11 
14 


Dynamic contention assignment field* 1/pad 


15 
18 


Dynamic contention assignment field* 2/pad 


19 
22 


Dynamic contention assignment field* 3/pad 


23 
26 


Dynamic contention assignment field* 4/pad 


27 
30 


Dynamic contention assignment field* 5/pad 


31 
34 


Dynamic contention assignment field* 6/pad 


35 
38 


Dynamic contention assignment field* 7/pad 


39 
42 


Dynamic contention assignment field* 8/pad 


43 
46 


Dynamic contention assignment field* 9/pad 


47 
50 


Dynamic contention assignment field* 10/pad 


51 
54 


Dynamic contention assignment field* 1 1/pad 


55 
58 


Dynamic contention assignment field* 1 2/pad 


59 
62 


Dynamic contention assignment field* 1 3/pad 


63 
66 


Dynamic contention assignment field* 1 4/pad 


67 
70 


Dynamic contention assignment field* 1 5/pad 


71 
74 


Dynamic contention assignment field* 1 6/pad 


75 
78 


Dynamic contention assignment field* 1 7/pad 


79 
82 


Dynamic contention assignment field* 1 8/pad 


83 
86 


Dynamic contention assignment field* 1 9/pad 


87 
90 


Dynamic contention assignment field* 20/pad 


91 
103 


Padding bytes 


104 
107 


TOD check 
(see clause 7.5.1) 



7.5.7.1 Dynamic contention assignment field definition 

The details of the contention field format is shown in table 7.37. 

Table 7.37: Dynamic contention assignment field format 



Byte/bit 


bit? 


bite 


bit 5 bit 4 


bits bit 2 biti bit 





Spare 


Rate 


D/C (2-bit) 


Sub-band designator (4-bit) 


1 


Spare 


carrier designator (7-bit) 


2 


Spare 




Spare 


3 











The D/C field for dynamic contention assignments shall always designate the data/control mode as "control or data". 
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7.5.8 Void 



7.5.9 SLC test messages 

The SLC test message format is shown in figure 7.23. 



(MSB) (LSB) 
Bit? Bite Bits Bit 4 Bit 3 Bit 2 Bit 1 Bit 


Byte 


Version Number (4 bits) R/C Message type (3 bits) 





Sequence Number (16 bits) 


1 


2 


Test Id (4 bits) Pacl<et type (4 bits) 


3 


Time Sent 


4.. 12 


Time Received 


13. .21 


Return MAC Address 


22..25 


Transaction ID Number of destination addresses 


26 


List of recipients (up to 15 address of 32 bits eacli) 


27.. 86 


Padding bytes 


87. .to end 

of 
message 



Figure 7.23: SLC Test message format 

7.5.9.1 Version Number 

This field shall be set to "0000". The ST shall ignore all received test messages with versions greater than "0000". 



7.5.9.2 



R/C 



This field determines whether the ST is to collect the diagnostics information or send it back. If this bit is set to "1" the 
receiving ST shall send the packet back to the originating ST. If this bit is set to "0", the receiving ST shall collect the 
diagnostics information. 



7.5.9.3 



Message type 



SLC test message type field is coded as per table 7.38. 

Table 7.38: SLC test message type field definition 



Message type 


Definition 


000 


SLC peer-to-peer delay test 


001 


Satellite delay test 


All other values 


reserved 



7.5.9.4 



Sequence number 



The sequence number field is an optional field. A sequence number may be associated with each message within a flow. 
The sequence number starts from zero and is incremented for each message within that flow. If this field is not used 
then the ST shall code it as all zeros. 

7.5.9.5 Test Id 

For each individual test, a new test-id is created by the initiating ST. 
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7.5.9.6 Packet type 

The packet type field identifies the packet type as defined in table 7.39. 

Table 7.39: packet type field definition 



Packet type 


Definition 


0000 


Satellite loopback packet 


0001 


Satellite connectivity QoS packet 


0010 


Specified channel test packet 


0011 


Background QoS packet 


All other values 


reserved 



7.5.9.7 



Time sent 



The time sent field coding is conditional on the value of the message type field. When the message type is peer-to-peer 
delay test, this field is coded as per clause 7.5.9.7.1. When the message type is satellite delay test, this field is coded as 
per clause 7.5.9.7.2. 



7.5.9.7.1 



SLC peer-to-peer delay timestamp 



The time sent field has two subfields: the downlink frame number and the slant path delay. The downlink frame number 
is the absolute downlink TOD[39,0] at the time the diagnostic message is generated prior to calculation of CRC. The 
slant path delay, tgp, is defined in BSM RSM-A TS 102 188-6 [4]. The resolution of the delta offset is 1 msec. 



(MSB) (LSB) 
Bit? Bite Bits Bit 4 Bit 3 Bit 2 Bit 1 BitO 


Byte 


downlink frame number 



1 
2 
3 

4 


Slant path delay 


5 




6 


Spare 


7 
8 



Figure 7.24: Time sent format 



7.5.9.7.2 



Satellite delay timestamp 



The time sent field has one subfield called the uplink timeslot number. The uplink timeslot number is the absolute 
uplink TOD[39,0] at the transmitter at the start of the time slot used for the transmission where the Isb is 3 msec. It is 
equivalent to the downhnk TOD[39,0] counter + t^p. See BSM RSM-A TS 102 188-6 [4]. 



(MSB) 
Bit? 


Bite 


Bits Bit 4 Bit 3 Bit 2 


Biti 


(LSB) 
BitO 


Byte 


uplink timeslot number 



1 
2 
3 

4 


Spare 


5 


6 


7 
8 



Figure 7.25: Time sent format 
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7.5.9.8 



Time received 



The time received field coding is conditional on the value of the message type field. When the message type is 
peer-to-peer delay test, this field is coded as per clause 7.5.9.8.1. When the message type is satellite delay test, this field 
is coded as per clause 7.5.9.8.2. 



7.5.9.8.1 



SLC peer-to-peer delay timestamp 



The time received field has two subfields. The downlink frame number is the downlink TOD[39,0] counter at the 
receiver ST after calculation of CRC. The slant path delay, t^p is defined in BSM RSM-A TS 102 188-6 [4]. The 
resolution of the delta offset is 1 msec. 



(MSB) (LSB) 
Bit? Bite Bits Bit 4 Bit 3 Bit 2 Bit 1 BitO 


Byte 


downlink frame number 



1 
2 
3 

4 


Slant path delay 


5 




6 


Spare 


7 
8 



Figure 7.26: Time received format 



7.5.9.8.2 



Satellite delay timestamp 



The time received field has one subfield called the downlink frame number. The downlink frame number is the absolute 
downlink TOD[39,0] at the received for the downlink frame in with the message was received where the Isb is 3 msec. 
It is equivalent to the downlink TOD[39,0] counter + t^p. See BSM RSM-A TS 102 188-6 [4]. 



(MSB) 
Bit? 


Bite 


Bits Bit 4 Bit 3 Bit 2 


Bit1 


(LSB) 
BitO 


Byte 

























1 






downlink frame number 






2 
3 

4 






Spare 






5 


6 


7 












8 



Figure 7.27: Time sent format 

7.5.9.9 Return MAC address! 

The return MAC address is the source ST's Destination MAC Address. 

7.5.9.1 Number of designated addresses 

The number of designated addresses field indicates the number of recipients which are listed in the list of recipients 
field. Up to 15 recipients can be addressed for a multicast test. 

7.5.9.1 1 List of recipients 

This field provides a list of recipients in case the transmission is multicast. The recipients shall be identified by their ST 
Site IDs. When there are less than 15 recipients, unused bits in this field shall be coded all zeros. 



£75/ 



92 



ETSI TS 102 189-2 VI. 1.1 (2004-03) 



7.5.9.12 Padding bytes 

The number of padding bytes to be added to the end of the message shall equal TestMsgLength in bytes. See clause 8. 
The maximum SLC-PDU is 64 000 bytes. The Padding bytes field shall be truncated if necessary so that the maximum 
SLC-PDU length will not be exceeded after all necessary headers and CRC fields are added. 

When the message type field is satellite delay test, the TestMsgLength shall be ignored and no padding bytes shall be 
added. 



8 Configurable parameters 

8.1 SLC un-ack mode configurable parameters 

The SAR configurable parameters are for both the Sending ST and the Receiving ST. These parameters assist the SAR's 
segmentation process and reassembly process on any given RSM-A system terminal. 

8.1.1 Timers 

Timers used in SLC-unack mode are defined in table 8.1. 

Table 8.1 : Timers description in SLC-unacl< mode 



Timer 


Started 


Stopped 


Action at expiry 


Value 


Reassennbly_timer 


When first segment of a 


Stopped on 


All the segments of 


5 000 msec 




packet is received 


receiving the last 


partially received 






Restarted on receiving 


segment of a 


packets are 






the next segment of a 


fragmented 


discarded. 






segmented pacl<et. 


packet. 







8.2 SLC ack-mode configurable parameters 



Void 



8.3 SLC CRC configurable parameters 

Thresholds are used to determine which CRC to apply to data. These parameters are configurable and are listed in 
table 8.2. 

Table 8.2: CRC threshold parameters 



Parameter 


Default value 


TH1 





TH2 


4094 


TH3 


32764 
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8.4 MAC configurable parameters 
8.4.1 Bandwidth control parameters 

The following timers are used by the ST during the handshake with the network. 

Table 8.3: Bandwidth control protocol timers 



Timer 


Started 


Stopped 


Action at expiry 


Value 


Response Timer 


When the rate request 
is initially sent. It is 
also restarted on every 
cell-cast message 
where an allocation is 
received from the 
network for the 
existing rate-request. It 
is also restarted after 
sending rate 
deallocation request 


On receipt of rate 
denied message or on 
successful completion 
of rate deallocation 
procedure 


Re-send the rate 
request over to 
network and restart 
the timer. After 
MAX_NO_RETRY 
expiries, abort attempt. 
If CC transition is 
detected (refer to 
clause 7.5.2.2.10), 
take no further action. 
If CC transition is not 
ongoing, declare 
failure to CM. If this 
timer is started after 
sending a rate 
deallocation request 
then retransmit rate 
deallocation request 
and restart this timer 


1 frames 


Allocation Timer 


When a volume 
request is initially sent 
over to the network or 
each time a non-final 
partial allocation is 
received 


When an allocation 
arrives from the 
network via the 
cellcast message 


Increment the current 
value of the allocation 
timer by 

bcp_alloc_step and 
retransmit the BoD 
request 


Bounded by 
bcp_alloc_min and 
bcp_alloc_max. 
Increased by 
bcp_alloc_step for 
each failure and 
decreased by 
bcp_alloc_step for 
each success. 
Default values: 
bcp_alloc_min= 
1 frames 
bcp_alloc_step= 
2 frames 
bcp_alloc_max= 
30 frames 



The following configurable parameters are used for controlling the operation of the Bandwidth control procedures. 
Table 8.4: Bandwidth control procedure variable definitions 



Variable 


Purpose 


BOD Allocation Min Timer 


Used in computation of timeout for BOD volume requests, as defined in 
clause 6.3.3.1 . The timeout is lower bounded by this parameter. 


BOD Allocation Max Timer 


Used in computation of timeout for BOD volume requests, as defined in 
clause 6.3.3.1 . The timeout is upper bounded by this parameter. 


BOD Allocation Step Timer 


Used in computation of timeout for BOD volume requests, as defined in 
clause 6.3.3.1 . On each successive timeout, the timeout value is 
incremented by this parameter. 


BODMaximumBODRequestSize 


The maximum amount of data for which an allocation can be requested 
in a single BOD volume request. 


BOD Response Timer 


The timeout value for waiting for a response to a BOD rate request. 


BOD Rate Request Retries 


The maximum number of retries allowed for a BOD rate request. 
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8.4.2 Contention access protocol parameters 

The following configurable parameters govern operation of the contention channel access protocols. 
Table 8.5: Contention access protocol variable definitions 



Variable 


Purpose 


N_ulpc 


Configurable system wide parameter wliicli defines tlie frame 
periodicity of seized slots using PA-1spnf protocol 


Njimeout 


Maximum number of consecutive ULPC timeouts allowed on a 
seized PA-1spnf slot, after which the slot must be released. 


Pmax 


Used in computation of transmission probabilities for SA access, as 
defined in clause 6.3.5.2.6. The transmission probability is upper 
bounded by this parameter. 


Pmin 


Used in computation of transmission probabilities for SA access, as 
defined in clause 6.3.5.2.6. The transmission probability is lower 
bounded by this parameter. 


N_nulltx 


Defines maximum consecutive NULL packets that may be 
transmitted on a seized PA-1spnf slot. 


Umax 


Used in computation of PA-1spnf channel loading, as defined in 
clause 6.3.5.3.4. A PA-lspnf channel is considered unavailable if 
the channel loading equals or exceeds this parameter. 


N_1spf_nulltx 


Defines maximum consecutive NULL packets that may be 
transmitted on a seized PA-1spf slot. 


Lgmax 


Used in computation of PA-1spf channel loading, as defined in 
clause 6.3.5.4.4. A PA-1 spf channel is considered unavailable if the 
channel loading equals or exceeds this parameter. 



8.4.3 Miscellaneous MAC parameters 

The following configurable parameters govern miscellaneous aspects of the MAC: 

Table 8.6: Miscellaneous MAC parameters 



Variable 


Purpose 


maxQueueDepth 


Parameter that defines the maximum amount of data (in number of RSM- 
A packets) that can be queued in a CR/CRWB/LVLL/Ack-Return queue. 
Any SDU that if enqueued would cause the associated maxQueueDepth 
to be exceeded is either dropped (for CR/CRWB) or remapped to the 
alternate UDTS instance (for LVLL/Ack-Return). 


serviceWeight 


Parameter that defines the relative weight of a HPB/NPB/CRWB queue 
used when servicing HPB/NPB/CRWB queues using available Volume 
PTOs. 


volumeBoDTriggerThreshold 


Parameter that defines a threshold queue depth for a CRWB queue which 
if exceeded results in a volume request being made for the amount of 
data exceeding this threshold. 


SatellitePacketRefillSize (SPRS) 


For a token bucket the number of tokens to add to the bucket every RTP 
time period. 


RefillPeriod (RTP) 


For a token bucket the time period to periodically add SPRS amount of 
tokens to the bucket. 


maxBurstSize 


For a token bucket the maximum amount of tokens that may be stored in 
the token bucket. 
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Annex A (normative): 

Uplink Frame, Beams and Channels 

A.1 Uplink frame structure, beams and channels 

This clause summaries the up-Unk frame structure and beams and channels, which will help in understanding the 
bandwidth control (that deals primarily with the managing the uplink channels and time slots) aspects. In case of 
disagreement, BSM RSM-A TS 102 188-2 [2] and TS 102 188-6 [4] are the normative documents. 

The ST may operate in one of the four uplink carrier modes: 128K, 512K, 2MB and 16MB. The uplink frame duration 
is 96 ms and is divided into 32 time slots of 3ms each. The ST shall transmit one burst within a time slot. The number of 
MAC blocks, which the ST maps into a burst, varies for different carrier modes. A burst contains one MAC block for 
512K channel, 4 MAC blocks on a 2-MB channel, and 32 MAC blocks for 16MB channel. 

The ST receives index assignments from the BCS in the bandwidth assignment message that are consecutive. Each 
assignment contains two fields: a start index and a number of consecutive indices. The start index is a binary value, 
which varies from to 31. The number of consecutive indices is an integer, which varies from 1 (coding of "00000") to 
32 (coding of "1 1 1 11"). The ST shall use these values in the time slot mapping function below to determine the actual 
time slots, which are assigned to the ST. This is true for all forms of assignments from the network, i.e. MIP 
assignments, HVUL assignments and BC assignments. Once the set of time slots is known, the ST shall map MAC 
blocks into these assignments such that the RSM-A packets are transmitted in order. In other words, the packets sent 
using the assigned time slots shall arrive at the destination ST in the correct order. 

The conversion is as follows. If an index x has been assigned to the ST, and k is the uplink cell ID (see BSM RSM-A 
TS 102 188-1 [1] then the time slot assignment, y, is determined using the time slot mapping function f2 for carrier 
mode of 128 kbps and fl for all other carrier modes. 

For a 128kb/s channel: y = f2(x) where f2(a) is the entry in the array f2 corresponding to the index a. 
Note that < y < 7. 

For any other channel y = fl((xH-k) mod 32) where fl(a) is the entry in the array fl corresponding to index a. 
Note that 0<y< 31. 

The time slot mapping functions are the ordered arrays: 

fl[]={0,16,8,24, 4,20,12,28,1,17,9,25,5,21,13,29, 2,18,10,26,6,22,14,30,3,19,1 1,27, 7,23,15,31} 

for the 512kb/s and higher carrier modes; and 

f2[] = {0,4,2,6,1,5,3,7} 

for the 128kb/s carrier mode. 
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Annex B (informative): 
Message sequence diagrams 

B.1 IVIessage sequence diagrams 

The following clause illustrates the various scenarios of the bandwidth-on-demand protocol. 

B.1 .1 Rate request - Positive response 

The Rate request protocol is described in clause 6.3.3.2. 



ST/BC 



Bandwidth Request message 



Bandwidth Assignment message 



BCP 



Figure B.1 : Rate request - Positive response 

The ST MAC informs the upper layer about the granted assignment. The ST shall transmit the data in the newly allotted 
slots in the frame number, for which the new assignment is valid. 

B.1 .2 Rate request - Negative response 

The network may respond with a negative acknowledgement for one of the following reasons: 

• The request packet received from the ST is invalid (invalid number of requests or interface version or too 
many slots requested, request already exists). 

• The network cannot allocate the requested bandwidth. 
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ST/BC 



Bandwidth Request message 



Negative Acknowledgement message 



Bandwidth Request message 



Bandwidth Assignment message 



BCP 



Figure B.2: Negative response due to an invalid request header in the packet 

Each step is explained in the following list: 

1) The network discovers that the packet has been formatted incorrectly, i.e. the number of requests field is 
incorrectly filled, or the interface version specified is invalid, and the network sends a Negative 
Acknowledgement message. 

2) The MAC sub-layer of the ST receives the Negative Acknowledgement message with cause: Bad packet 
header. The ST shall cancel the timer. 

3) The MAC sub-layer issues a corrected rate request. 

4) The network receives the correctly formatted Bandwidth request message and allocates the requested 
bandwidth and sends the assignment via the Bandwidth Assignment message. The ST processes the 
Bandwidth Assignment message and identifies the assignments addressed to it. It cancels the timer. 

B.1 .2.1 Rate request - Negative response due to insufficient bandwidtin 



ST/BC 



BCP 



Bandwidth Request message 



Negative Acknowledgement message 



Figure B.3: Negative Response due to insufficient bandwidth 

1) The network can not allocate the requested bandwidth and sends a Negative Acknowledgement message with 
cause: No bandwidth. 

2) The ST receives the Negative Acknowledgement message. 

3) The MAC sub-layer shall convey this 'Rate denied' information to upper layer, the connection management 
entity in the ST. 

4) The MAC sub-layer shall delete all queued data for this connection and clear it. 
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B.1 .3 Message corruption/Lost 



ST/BC 



BCP 



Bandwidth Request message 



o 



Bandwidth Request message 



Bandwidth Assignment message 



Figure B.4: Message corruption/lost during transmission 

B.1 .4 Rate request - Changes in the traffic pattern 

See clause 6.3.3.3. 



ST/BC 



BCP 



Bandwidth Request message 



Bandwidth Assignment message 



Figure B.5: Rate request - Rate change request 
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B.1 .5 Rate de-allocation 



See clause 6.3.3.4. 











ST/BOD 


BCP 




Bandwidth Request message 













Figure B.6: Rate de-allocation 



B.1.6 Volume request 



See clause 6.3.3.1. 



ST 



Bandwidth Request message 



Bandwidth Assignment message 



BCP 



Figure B.7: Volume request 
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B.1 .7 Volume request - partial assignment 



See clause 6.3.3.1. 



ST 



BCP 



Bandwidth Request message 



Bandwidth Assignment message (partial assignment) 



Data 



Bandwidth Assignment message (partial assignment) 



Bandwidth Assignment message (completed assignment) 



Figure B.8: Partial allocations 
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Annex C (informative): 
Void 
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Annex D (normative): 
Satellite terminal capability 

D.1 ST basic capability set 

The basic capability set for the ST is given in table D.l. 



Table D.l : Basic required capability set of an ST 



Capability 


Description 


Link Protocol 


SLC Unacknowledge mode only 


Compression 


No SLC compression 


CRC 


All four options supported 


Linl< layer data confidentiality 


ST should support but not a basic capability, if supported. 
ST shall pad all encrypted SDUs out to multiple of 8 octets 
prior to encryption 


User Data Transport Services (UDTS) supported 


Constant Rate (CR), Constant Rate with Burst (CRWB), 
Low Volume Low Latency (LVLL), High Priority Burst, Ack 
Return and Normal Priority Burst 


Packet Delivery Service (PDS) 


High priority Rate, High Priority Volume, Normal Priority 
Volume, Slotted Aloha (SA), Persistent aloha (PA) 


Extension header 


ST shall recognize E bit read length and skip. ST is not 
required to read the extension header 


SAR 


ST shall support up to at least two segments in one packet 


SA 


ST shall support supervisory and data/control SA channel 
types and shall treat all other code points as data/control 


PA 


ST shall support PA, ST may support PA-1spf 


Retransmission 


ST may support up to one retransmission of data packets 
only on the SA channel. ST shall not retransmit BoD 
packets or management packets 


Uplink Channel Rate 


ST shall support rates up to 512 kbps, and may support 
rates up to 16 Mbps 


Multicast 


ST shall receive multicast packets and should source 
multicast packets 


Diagnostic Support 


As defined in clause 5.8 



£75/ 



103 



ETSI TS 102 189-2 VI. 1.1 (2004-03) 



Annex E (informative): 
CRC Examples 

An implementation of the CRC calculation given in clause 5.4 will calculate the CRC values given in table E.l. 

Table E.l : Examples of CRC values 



Input data 


CRC type 


CRC value (hexadecimal) 


1 byte of 0x61 (note 1 ) 


CRC-ST-16 


Of 46 


1 byte of 0x61 (note 1 ) 


CRC-ST-32 


ef 74 60 be 


1 byte of 0x61 (note 1 ) 


CRC-ST-64 


00 00 00 00 00 00 cf bb 








50 bytes of 0x41 (note 2) 


CRC-ST-16 


37 be 


50 bytes of 0x41 (note 2) 


CRC-ST-32 


6a19f3a2 


50 bytes of 0x41 (note 2) 


CRC-ST-64 


88 88 7b 53 e5 cd 88 83 








1000 bytes of 0x5a (note 3) 


CRC-ST-16 


db65 


1 000 bytes of 0x5a (note 3) 


CRC-ST-32 


fc 5b 98 87 


1 000 bytes of 0x5a (note 3) 


CRC-ST-64 


8b 48 44 74 be ef c1 fb 


NOTE 1 : The value 0x61 is the ASCII representation for the letter "a". This input is 

one byte representing one instance of ASCII value. 
NOTE 2: The value 0x41 is the ASCII representation for the letter "A". This input 

represents a string consisting of that letter appearing 50 times. 
NOTE 3: The value 0x5a is the ASCII representation for the letter "Z". This input 

represents a string consisting of that letter appearing 1 000 times. 
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